Geliştiricilerin tasarımcılarla yaşadığı 6 hayal kırıklığı

Sadece eğlenmek için tasarlamıyorsanız – ya da HER ŞEYİ yapabilen efsanevi ‘tek boynuzlu atlardan’ biri değilseniz – bir noktada, sevimli küçük resimlerinizi çekmekle görevli biriyle karşılaşacaksınız (ve muhtemelen onunla ilgileneceksiniz) ve onları gerçek bir dünya ürününe dönüştürmek. Kediler ve köpekler gibi, bu ilişkiler de tarihsel olarak gergin olarak biliniyor.

Elbette tasarımcı / geliştirici ilişkilerinin tamamı çekişmeli veya karşılıklı güvensizliğe dayalı değildir. Aslında, duvarların zorunluluktan yıkılması gereken çevik ortamlarda giderek daha fazla tasarımcı ve geliştirici birlikte çalışıyor.

Yine de bazı hastalıklar devam edecek. Bu stresi azaltmaya yardımcı olmak için geliştiricilerin tasarımcılarla yaşadığı en yaygın hayal kırıklıklarını ve onlardan kaçınmak için nasıl çalışabileceğinizi anlatıyorum.

01. Elli gri ton var!

Sorun : Çıktı, geliştiricinin geçmek zorunda olduğu ve her grinin biraz farklı bir değeri olan 53.002 katmana sahip birPhotoshop / Illustrator / Sketch dosyasıdır.

Çözüm : Basitçe ifade edersek, bir stil kılavuzuna ihtiyacınız var. Görsel kompozisyondaki tüm değerlerin “piksel mükemmel” olmasına güvenmek yerine, önemli standart değerleri (renkler, kenar boşlukları, dolgu, kenarlıklar vb.) Tek bir ortak referansta kaydedin. Bu, geliştiricinin yapması gereken tahmin ve yorumlamayı büyük ölçüde azaltır ve geliştirme sürelerini önemli ölçüde kısaltabilir. Bunu CSS kullanarak yaparsanız bonus puanlar ve renk gibi değişken değerleri yakalamak için SASS veya LESS kullanarak ultra bonus puanlar kazanırsınız.

02. Bu şeyin içine giren içeriğe baktın mı?

Sorun : Tasarım, yer tutucu Lorem Ipsum metni kullanılarak teslim edilir, ancak lastik yola çıktığında, bu, ürüne giren gerçek içeriğe benzemez.

Çözüm : İçerik kraldır! Tasarımların içeriğe uyması gerekir, tersi değil. Geliştiriciler, içeriğin tasarımlara çarptığı yerin ön saflarında yer aldığından, öncelikle içeriği göz önünde bulundurarak tasarlamadığınızda çantayı elinde tutanlardır. Tasarımcılar, tasarımları sonlandırmadan önce tam bir içerik envanterine sahip olduklarından emin olmalıdır.

03. Senin işin sadece güzelleştirmek, nasıl çalıştığını bana söylemek değil

Sorun : Tasarımcı, istediği şekilde çalışan, dikkatlice hazırlanmış etkileşimli / zamansal bir prototip yaratır, ancak hepsi “atılabilir” koddur.

Çözüm : Geliştiriciler, bir dizi statik diyagram elde etmeye ve ardından bunları nasıl çalıştıracaklarını bulmaya alışkındır. Etkileşimli prototip oluşturmaya doğru ilerlemek, genellikle kendi bölgeleri olduğunu düşündükleri şeye müdahale eder. Tasarım artık göründüğü gibi değil, aynı zamanda nasıl çalıştığıdır.

Ancak, bunun nasıl iletişim kurulacağına dair manzara değişiyor ve tüm geliştiriciler nasıl etkili bir şekilde iletişim kuracaklarını öğrenmedi. Yani tasarımcıların işi onlarla konuşmaktır. Onlara, işlerini elinden almaya çalışmadığınızı, sadece fikirlerinizi netleştirmek için daha iyi yollar bulmaya çalıştığınızı bildirin. Geliştirici eski “kodu atma” argümanını kullanırsa, onlara “statik diyagramlarla ne yaptığınızı düşünüyorsunuz?” Diye sormanız yeterlidir.

04. Yayınlandığında kullanılabilirlik testi yapacağız

Sorun : Çevik dünyada, kullanıcı testi lüks bir şeydir ve geliştiriciler için İşi yapmaktan gereksiz bir dikkat dağıtma gibi görünebilir. Ancak tasarımcılar, kullanıcı testinin yalnızca kararları lansmandan önce bilgilendirmesi durumunda etkili olduğunu biliyor.

Çözüm : Tasarımcılar sprintleri planlarken, test etmelerine ve geliştirme aşamasına geri dönmelerine olanak tanıyacak kullanıcı testi ani artışları oluşturmalıdır. Geliştiriciler bu iyileştirmeleri planladıkları sürece, genellikle gerekliliklerini kabul ederler.

05. Bunu yapamam

Sorun : Tasarımlar yetkiler tarafından onaylandı, ancak geliştirici, onlara ‘öyle yap’ söylenene kadar onları görmüyor. Tek sorun, tasarımcı neyin mümkün olduğunu değil, ne yapmak istediğini düşünüyordu.

Çözüm : Öncelikle, tasarımcıların tasarladıkları platformun yeteneklerine dayandırılması gerekir. İster web, ister iOS, Android veya başka bir şey olsun, ortamınızı bilin. İkincisi, geliştiriciyi tasarım aşamasında asla yeterince erken getiremezsiniz. En azından geliştiricileri inceleme oturumlarına dahil edin, böylece olası sorunları kontrolden çıkmadan çözebilirsiniz.

06. Ne zaman istiyorsun?

Sorun : Ürün yaratmanın sonunda geldiği için, özellikle teslim tarihi varsa diğer aşamalar uzarsa geliştirme aşaması genellikle kısa sürede değişir. Hala bir şelalede veya hatta “hibrit-çevik” süreçte çalışıyorsanız, bu sorun karmaşık hale gelir.

Çözüm : Lean-UX ile çevik olamıyorsanız, en azından geliştiricileri her aşamaya dahil edin ve bitirmemiş olsanız bile yapabilecekleri üzerinde çalışmaya başlamalarına izin verin tüm tasarım.

Nihai ekranları bitirmeden tasarımları yayınlama konusunda çok inatçıydım, çünkü aşağı akışta alınan kararlar nedeniyle önceki ekranlarda bir şeyleri değiştirmem gerekeceğinden endişeleniyordum. Bu, geliştiricilerin gönül yaralamasına neden olmadı ve onları yinelemeye önceden hazırlarsam, değişikliklerimi yaptırıp bölümleri tamamladıkça onları çalıştırmaya devam edebileceğimi çabucak öğrendim.

İlk olarak www.jasonspeaking.com 7 Mart 2016’da yayınlanmıştır.

Jason CranfordTeague, The CranfordTeague Group ’un kurucu ortağı ve baş kreatifidir ve tasarımcı olmayanlara harika bir kullanıcı deneyimi yaratma konusunda eğitim verme konusunda uzmanlaşmıştır.