Topp 6 frustrationer designare har med utvecklare

Vi vet det utvecklare kan bli frustrerade över designers , särskilt när designern designar något som är omöjligt att bygga. Men det finns mycket för designers att bli frustrerade över utvecklare.

Design ses ofta som en 'mjuk färdighet' som handlar om en uppfattning om estetik, inte hårda regler, än mindre den strikta logiken i koden. Ändå arbetar designers i flera år med att perfektionera ett hantverk, inte bara spotta oinformerade idéer. Att kunna förklara och formulera 'metoden bakom designgalan' är dock inte alltid lätt och sällan snabbt, vilket leder till många projektfrustrationer. Lyckligtvis finns det vanligtvis ett sätt att sprida spänningen.

01. Jag designade det på det sättet av en anledning

Bildkälla: Cat Donmit på Flickr

Bildkälla: Cat Donmit på Flickr

Problemet : Designern tillbringar veckor med att skapa noggrant utformade visuella kompisar och specdokument, bara för att få dem till synes ignorerade av utvecklaren. Utöver att ignorera specifikationerna tillåter vissa utvecklare helt enkelt webbläsarens standardvärden att stå utan förändring om de inte uttryckligen anges i dokumentation, inte bara visas i visuella komp.

Designern antar att utvecklaren kommer att titta noga på kompisarna och försöka få dem att matcha 'pixel-perfect'. Detta leder dock i allmänhet till gränssnitt som känns trånga eller dåligt organiserade, trots de bästa ansträngningarna från designers.

Lösningen : Designers bör inte anta något och veta att dokumentation aldrig räcker. En bra designguide är det första steget mot att eliminera detta problem, men designers måste också arbeta sida vid sida med utvecklarna och regelbundet granska sitt arbete för att säkerställa att det är vad som är avsett i en designacceptansgranskning när utvecklaren känner sig bekväm med vad de har gjort.

hur man byter färg till en annan färg i Photoshop

02. MVP!?!? Det är allt MVP!

Bildkälla: Jugbo på Flickr

Bildkälla: Jugbo på Flickr

Problemet : Utvecklaren har en begränsad tid för att skapa slutprodukten, ännu mindre för varje sprint, så de kommer att prioritera funktioner och funktionalitet baserat på den 'minimala livskraftiga produkten' som uppfyller produktspecifikationerna. De flesta formgivare ser dock produkten som en integrerad helhet, inte en serie sammankopplade komponenter. Men MVP definieras ofta inte förrän i utvecklingsfasen, så det kan kännas mer som utvecklare fattar beslut baserat på deras schemaläggningsbehov snarare än användar- och produktbehov.

Lösningen : MVP måste definieras under produktens inledande faser och verkligen vara den minsta livskraftiga produkten, inte bara den enklaste att göra, för olika utvecklingsfaser / sprints. Designers kan arbeta för att skapa en produkt som byggs upp i steg, snarare än att slutföras på en gång. Detta bör också göra det lättare för utvecklare att planera därefter.

03. Det här tar hur lång tid?!?!?

Bildkälla: Jon Hathaway på Flickr

Bildkälla: Jon Hathaway på Flickr

Problemet : Designern har spenderat månader på att planera, undersöka och skapa mönster för att möta användarnas behov, bara för att få veta att det tar mycket längre tid än väntat på grund av motstridiga projektplaner, personalbrist och den fruktade omfattningen.

Lösningen : En av fakta i något UI-utvecklingsprojekt är att utvecklingen kommer sist och i allmänhet pressas i tid av stegen innan (jag har aldrig känt upptäckts-, definierings- eller designfaserna att gå snabbare än planerat för att ge utvecklingen mer tid) .

En väg runt detta är genom Agile i kombination med Lean UX för att möjliggöra utveckling parallellt med design, så att utvecklarna kan komma igång innan designen är helt låst. Detta tillvägagångssätt är inte utan risker (design kan behöva omprövas) men leder i allmänhet till snabbare produktion och gladare projektledare. Och verkligen, är det inte det vi alla vill ha?

04. Vad menar du 'Jag kan inte göra det!'?

Bildkälla: Peter Kaminski på Flickr

Bildkälla: Peter Kaminski på Flickr

Problemet : Designern har skapat en riktigt cool upplevelse, men utvecklaren tar en titt på det och proklamerar, 'Det kommer aldrig att fungera.' En anledning till att utvecklare kanske inte kan göra något är att det inte kan göras, men oftare är det en av två andra orsaker: 1) det skulle ta för lång tid, längre än projektet har, eller 2) utvecklaren bara inte vet inte hur man gör det.

Lösningen : Om det inte kan göras kan det inte göras och designern måste tänka om lösningen. Om det bara tar för lång tid måste teamet bestämma om de ska skala tillbaka eller ta den tid som behövs. Men om utvecklaren bara inte vet hur man får det att fungera, måste designern visa dem exempel på platser där den önskade tekniken fungerar. Jag tycker att CodePen.io är min bästa gå till plats när jag behöver visa 'befintlig konst' för mina utvecklare.

05. Användbarhetstestning är INTE valfritt

Bildkälla: Dopey på Flickr

Bildkälla: Dopey på Flickr

Problemet : För många utvecklare betyder användbarhet att det fungerar enligt kraven. Om designers vill testa något bör de göra det innan utvecklaren spenderar långa timmar på att bygga användargränssnittet efter specifikationer. Men så mycket användbarhetstestning kan dock utföras med papper och klickbara prototyper. Ofta görs den mest effektiva testningen av användbarhet under utvecklingen.

hur man fixar hårt ljus i Photoshop

Lösningen : Planera användbarhetstestande spikar i alla Agile-projekt med iterationer som ger feedback till produktens utveckling.

06. De berättar för mig hur jag ska designa igen!

Bildkälla: Amy McTigue på Flickr

Bildkälla: Amy McTigue på Flickr

Problemet : En utvecklare läser en artikel om användbarhet av Jakob Nielsen, och plötsligt är de en användar- och designexpert. Designers spenderar år på att utveckla sina förmågor, kunskaper och skicklighet. Ett problem är att eftersom alla har en 'åsikt' om design (informerad eller inte) i vissa projekt - särskilt där det kan finnas ett UX-team av en - drunknar deras röst ofta.

Lösningen : Det här är inte ett enkelt problem att lösa, eftersom det har mer att göra med interpersonell och gruppdynamik än med faktisk logik och resonemang. Det bästa sättet jag har funnit att hantera dessa situationer är att helt enkelt lyssna utan att bli defensiv. Låt dem säga och överväga vad de säger.

Har vad de har att säga meriter? Låt dem veta och förklara sedan varför du valde att gå den väg du gjorde, och erkänn till och med att du inte håller med befintliga 'bästa metoder' som föreskrivs någon annanstans. Ofta vill utvecklare bara känna som om designern helt enkelt lyssnar på dem.

Något annat?

Jag har beskrivit de sex frustrationer som jag ofta ser att designers har med utvecklare och tidigare detaljerat sex frustrationer utvecklare har med designers . Vad tycker du om detta och kan du lägga till i listan? Föreslå lösningar i kommentarerna nedan så att vi alla kan dra nytta av din erfarenhet.

Ord : Jason Cranford Teague

Jason Cranford Teague är Senior Creative Director på Capital One och undervisar workshops om erfarenhetsdesign för utvecklare, utveckling för design och tidsmässigt designtänkande.

Så här? Läs dessa...