5 Pet Peeves-ontwerpers hebben ontwikkelaars (en hoe ze te vermijden)
Katten en honden. Kaïn en Abel. Ontwerpers en ontwikkelaars. Dit zijn slechts enkele van de grote historische face-offs.
Ontwerpers en ontwikkelaars lijken vaak van verschillende planeten te komen en hebben een heel ander brein.
Ontwikkelaars willen dat een website goed werkt , ontwerpers willen dat het er goed uitziet .
Hoewel deze doelen elkaar veel overlappen (en ik ben hier natuurlijk een beetje stereotiep), komen de verschillen vaak neer op de verwachtingen van de ontwerper en ontwikkelaar van succes.
Het beheren van verwachtingen is een kwestie van communicatie: punten duidelijk naar de andere kant leggen, een raakvlak vinden en overeenstemming bereiken over doelen.
Oké, dus misschien is het niet zo eenvoudig, maar het is belangrijk voor beide partijen om elkaar tenminste te proberen te begrijpen .
In een poging om goodwill tussen ontwerpers en ontwikkelaars te bevorderen, zal ik enkele dierverminkingen delen die ik ben tegengekomen en de problemen onderzoeken die tot hen en hun oplossingen leiden.
Peeve # 1: "Waarom kan de ontwikkelaar het niet laten lijken op de comp?"
U maakt een fantastisch ontwerp en geeft de comp aan uw ontwikkelaar, maar wanneer u de site terughaalt, lijkt het een lappendeken van wat u hebt ontworpen.
Kwestie
Comps zijn geen webpagina's; ze zijn geen combinatie van HTML-, CSS- en JavaScript-code. Photoshop, Fireworks en Illustrator kunnen veel dingen doen die onmogelijk (of althans heel onpraktisch) zijn op het web, wat vaak betekent dat ontwikkelaars het ontwerp moeten verkleinen.
Oplossing
Praat met je ontwikkelaar terwijl je aan het ontwerpen bent, niet alleen daarna. Vraag hen of een effect dat u gebruikt gemakkelijk te bereiken is of dat er een beter alternatief bestaat. En als u meer te weten komt over Webontwikkeling, kunt u het verschil beter zien tussen wanneer uw ontwerp onpraktisch is en wanneer de ontwikkelaar gewoon slap af is.
Peeve # 2: "De kleuren zijn allemaal verkeerd!"
Je kiest kleuren niet willekeurig, maar ontwikkelaars lijken te denken dat 'dichtbij genoeg dichtbij genoeg' is.
Kwestie
Ik weet niet of dit geldt voor alle ontwikkelaars, maar ik heb ooit gewerkt met een ontwikkelaar die roodgroen kleurenblind was (hij was een grote fan van onze contentmanager, die al haar e-mails in roze tekst op een limoengroene achtergrond). Kleurenblind zijn belette hem echter niet om een kick-ass ontwikkelaar te zijn.
Oplossing
Als u wilt dat de kleuren goed zijn, geeft u alle kleurwaarden op de pagina op. Vertrouw niet op uw ontwikkelaar om de kleurwaarden te bekijken of de kleuren in Photoshop te proeven.
Je moet ook bedenken dat het probleem misschien niet bij de ontwikkelaar ligt, maar bij jou. Kleuren zien er anders uit op een Mac en in CMYK (als u per ongeluk die kleurruimte activeert). Zorg ervoor dat uw documentkleurenmodus en proefdrukken standaard zijn ingesteld op generiek RGB.
Peeve # 3: "Weten ontwikkelaars zelfs wat ' witte ruimte' betekent?"
Je hebt genoeg ademruimte rond elementen achtergelaten om een vloeiend oogpad te creëren en de leesbaarheid te verbeteren, maar de ontwikkelaar propt alles samen en vertelt je: "Het is de enige manier waarop het allemaal zal passen."
Kwestie
Ik heb eens tegen een ontwikkelaar geklaagd dat hij geen ruimte liet tussen de rand van een module en zijn inhoud, waardoor het voor de meeste mensen moeilijk was om te lezen. Hij antwoordde: 'Ik geef niets om andere mensen. Ik kan het lezen. "Hoewel de meeste ontwikkelaars niet zo ongevoelig zijn, zijn ze niet getraind in het boeien van positieve en negatieve ruimten om het oog van de bezoeker rond het ontwerp te leiden.
Oplossing
Als je echt wilt dat je ontwerpen zo precies mogelijk zijn, geef je de ontwerper dan niet alleen een comp en verwacht hij dat hij de spatiëring ontdekt. Geef de exacte breedten, hoogten en lengten op in een document met ontwerpspecificaties. Dit dient als een blauwdruk die u en de ontwikkelaar het eens zijn over hoe de dingen moeten worden verdeeld.
Definieer op zijn minst algemene regels voor marges en opvulling. Bijvoorbeeld: "Alle modules moeten minimaal 10 pixels opvulling hebben tussen de inhoud en de rand."
Peeve # 4: "De ontwikkelaar kan mijn ontwerpen nooit hetzelfde laten lijken in verschillende browsers."
Je kijkt naar de site in Firefox en het ziet er goed uit, maar wanneer je overschakelt naar Internet Explorer valt het in stukken.
Kwestie
Je moet sympathiek zijn voor de benarde situatie van ontwikkelaars als het erom gaat ontwerpen op elkaar te laten lijken in verschillende browsers. Elke browser heeft zijn eigen eigenaardigheden met tussenruimte. Het wordt steeds beter (vooral met de trage dood van Internet Explorer 6), maar het is nog steeds moeilijk om ze allemaal leuk met elkaar te laten spelen.
Oplossing
Ik laat in mijn ontwerpen over het algemeen een paar pixels wankelruimte toe om cross-browser problemen op te lossen, maar het helpt om te weten wat deze problemen zijn tijdens het ontwerpen, zodat je de ontwikkelaar kunt helpen deze te vermijden.
Wees niet bang om cross-browserproblemen aan te wijzen aan de ontwikkelaar en verwacht dat deze worden opgelost. Maar bij het oplossen van sommige ervan moet je je ontwerp aanpassen.
Peeve # 5: "Dit duurt hoelang ?"
Niets is meer deprimerend dan middernachtolie op dubbele tijd te branden om uw deel van een project op tijd klaar te krijgen, alleen om een LOE-ontwikkelingsniveau (Level of Effort) terug te krijgen dat de release-datum van het project een maand na het einde van de eeuwigheid weergeeft .
Kwestie
In een klassieke aflevering van Star Trek: The Next Generation , legt Scotty de feiten van het ingenieursleven uit aan Geordi La Forge: "Je hebt hem [kapitein Picard] niet verteld hoe lang het echt zou duren, of wel soms? Oh, schat. Je moet veel leren als je wilt dat mensen aan je denken als een wonderwerker. "Sommige ontwikkelaars denken van ontwerpers op dezelfde manier waarop Scotty denkt aan Starfleet-kapiteins.
Oplossing
Ontwikkelaars weten dat ze onvoorziene problemen zullen tegenkomen en zijn daarom geneigd hun schattingen schromelijk op te volgen. Dit zorgt er ook voor dat ze er erg goed uitzien als ze hun einde veel vroeger dan geschat krijgen. Beweeg met de ontwikkelaar naar een redelijke tijdlijn en houd deze dan vast. Als je een ontwikkelaar leert kennen, zul je hopelijk je eigen weg vinden om een "wonderwerker" te zijn.
Speciale bonus Peeve: "Ontwikkelaars begrijpen ontwerpers gewoon niet."
Of erger:
"De ontwikkelaar denkt dat ze een ontwerper zijn!"
Het is al erg genoeg als ontwikkelaars lijken te weigeren om het standpunt van de ontwerper te zien, maar dat verschil van mening kan meestal worden gemedieerd (meestal door een goede projectmanager). Wanneer de ontwikkelaar echter denkt meer over design te weten dan de ontwerper, kunnen gemoederen oplaaien.
Kwestie
Ik heb te maken gehad met meer dan één ontwikkelaar die een artikel heeft gelezen Jakob Nielsen en wilde me dan tijdens een vergadering vertellen over goede ontwerppraktijken. Dit toont niet alleen gebrek aan respect voor de ontwerper, maar vertraagt het project terwijl het debat plaatsvindt.
Oplossing
Het werken met allesomvattende ontwikkelaars is lastig, en de manier om met deze situaties om te gaan, hangt af van de grootte van het ego waarmee je te maken hebt. Over het algemeen vind ik het het beste om gewoon te luisteren naar wat ze te zeggen hebben en dan, als ze een punt hebben, het te erkennen en verder te gaan. Probeer niet zo mogelijk ruzie met hen te maken .
Vaak gaat hun klacht over een ontwerpregel die is verbroken. Wees niet bang om te erkennen dat je een regel hebt overtreden - dat is wat innovatieve ontwerpers doen - maar zorg ervoor dat je kunt rechtvaardigen waarom je het hebt gebroken .
Telkens wanneer ik me in deze situatie bevindt, denk ik terug aan mijn evaluatiedagen op de ontwerpschool, toen ik mijn werk moest verdedigen tegen een aantal behoorlijk harde kritieken. Deze sessies waren vaak ego-blauwe plekken, maar ze leerden me hoe ik snel mijn beslissingen kon verdedigen terwijl ik mijn kalmte behield.
Het lijkt misschien vernederend om voortdurend je beslissingen te moeten rechtvaardigen, maar hoe meer je de 'methode in je gekte' laat zien, hoe meer je zult merken dat je collega's jouw oordeel waarderen en vertrouwen .
Exclusief geschreven voor WDD door Jason Cranford Teague .
Welke huisdiereters heb je bij ontwikkelaars? We willen hier graag meer over weten, deel uw opmerkingen hieronder.