Ön Uç Geliştiriciler Tasarımcının Çalışmasını Nasıl Güçlendirebilir?

Bu makale çoğunlukla, kullanıcı arayüzlerini uygulamaktan hoşlanan ancak birlikte çalıştığınız tasarımcılarla beklentileri aynı hizaya getirmekte zorlanan sevgili Frontend Developer'a yöneliktir. Belki de "UI Geliştiricisi" veya "UX Mühendisi" olarak anılırsınız. Taşıdığınız unvan ne olursa olsun, işiniz (ve benimki) tasarım dosyalarına hayat vermekten daha fazlasını içerir. Tasarım ve geliştirme iş akışları arasındaki boşluğu doldurmaktan da sorumluyuz. Ancak o köprüyü geçerken birçok zorlukla karşı karşıya kalıyoruz.

Bugün, geçtiğimiz yıllarda tasarımcılarla daha verimli işbirliği yapmama yardımcı olan pratik ipuçlarını sizinle paylaşmak istiyorum.

UI Developers olarak bizim işimizin, tasarımcılara web'in nasıl çalıştığını öğrenme yolculuklarında yardımcı olmakla kalmayıp, aynı zamanda onların gerçekliğini ve dillerini öğrenmenin de bizim işimiz olduğuna inanıyorum.

UX Tasarımcılarının Arka Planını Anlama

UX tasarımcılarının çoğu (Web Tasarımcıları veya Ürün Tasarımcıları olarak da anılır), tasarım dünyasında ilk adımlarını Photoshop ve Illustrator gibi araçlar aracılığıyla attı. Belki de Grafik Tasarımcılardı : asıl amaçları logolar ve marka kimlikleri oluşturmak ve dergiler için mizanpajlar tasarlamaktı. Ayrıca Pazarlama Tasarımcıları da olabilirlerdi: reklam panoları basmak, afişler tasarlamak ve bilgi grafikleri oluşturmak.

Bu, çoğu UX tasarımcısının ilk günlerini mevcut ortamları olan ekrandan tamamen farklı bir paradigma olan baskı için tasarım yaparak geçirdiği anlamına gelir. Bu onların ilk büyük mücadelesiydi. Baskı ile uğraşırken, tasarımcılar piksel hizalamasına önem verdiler, ancak sabit bir alanda (kağıt). Dinamik bir düzen (ekranlar) ile uğraşmak zorunda değillerdi. Metin kırma veya etkileşim durumları hakkında düşünmek de işlerinin bir parçası değildi. Tasarımcılar ayrıca performans kısıtlamaları olmaksızın renkler, resimler ve tipografi üzerinde tam bir özgürlüğe sahipti.

Neyse ki, kendi kendini yetiştirmiş UX tasarımcıları topluluğu, geliştirmenin temellerini öğretmek, tasarımcıların kodlamayı öğrenmeleri gerekip gerekmediğini tartışmak ve geliştiricilere en iyi nasıl teslim edileceklerini anlamak için birçok çaba sarf etti. Aynısı geliştirme tarafı için de geçerliydi (bir dakika içinde bunun hakkında daha fazlası). Ancak, iki alan arasında hala sürtüşmeler oluyor.

Bir yandan, tasarımcılar, bir uygulamanın tasarımlarıyla uyuşmadığı her durumda şikayet ederler veya bunlar geliştiriciler tarafından net bir açıklama yapılmadan reddedildiğinde yanlış anlaşıldıklarını hissederler. Öte yandan, geliştiriciler, tasarımcıların teknik bir şeyler bildiğini, bunun doğru olmayabileceğini kabul edebilir. Hepimizin bundan daha iyisini yapabileceğimize inanıyorum.

Yeni Bir Düşünme Şeklini Kucaklamak

Oluşturduğumuz web siteleri ve uygulamalar çok çeşitli ekran boyutlarında görüntülenecektir. Her kişi bunları birden fazla cihazda kullanacak. Ortak hedefimiz, yolculukları boyunca tanıdık bir deneyim yaratmaktır.

Geliştiriciler olarak, tasarımcıların piksel hizalamaları konusunda seçici olduğunu düşündüğümüzde, bunun nedenini anlamamız gerekir. Bunun sadakat ve tutarlılığın ötesinde olduğunu kabul etmeliyiz. Birlikte çalışan tüm parçaların toplamı ile ilgili. Uyum. Bunu benimsemeli ve başarmak için elimizden gelenin en iyisini yapmalıyız. Tasarım ilkelerinin temellerini öğrenmek iyi bir başlangıç ​​noktasıdır . Doğru renkleri seçmenin önemini, hiyerarşinin nasıl çalıştığını ve beyaz boşluğun neden önemli olduğunu anlayın.

Not : "Geliştiriciler için Tasarım" olarak bilinen çevrimiçi bir kurs ve "Yeniden Düzenleme Kullanıcı Arayüzü" adlı bir kitap vardır - her ikisi de başlamanız için harikadır. Bunlarla, ayrıntılar için keskin bir gözle kullanıcı arayüzlerini uygulayabilecek ve tasarımcılarla iletişim kurarken önemli bir avantaj elde edebileceksiniz.

Tasarımcılarınızın Farkındalığını Büyütmek

Tasarımcıların web'i sizin kadar bildiğini kabul edebilirsiniz. Pekala, olmayabilirler. Aslında, zorunda değiller! Geliştiriciler olarak, onları web'in mevcut durumuyla güncel tutmak bizim sorumluluğumuzdur.

Bu yelpazenin iki tarafıyla çalıştım: Tarayıcı uyumluluğunu düşünmeden her şeyin (karmaşık filtreler, yeni kaydırma davranışları veya özel form girdileri gibi) oluşturulabileceğini düşünen tasarımcılar. Sonra, "web'in düşük sınırlamaları" hakkında varsayımlara sahip tasarımcılar var ve kendi başlarına bir şeyin uygulanmasının imkansız olduğunu varsayıyorlar. Onlara web tasarımının gerçek olanaklarını göstermeli ve sınırlamaların becerilerini engellemesine izin vermemeliyiz.

Onlara Kodlamayı Öğretin, Kodlamayı Değil

Bu çelişkili görünüyor ama bana katılıyor: nasıl kod yazılacağını bilmek bir geliştiricinin işinin özüdür. Her gün yeni şeylerin ortaya çıktığı hızlı tempolu bir sektörde çalışıyoruz. Tasarımcılardan kod yazmayı öğrenmelerini istemek, bizden ikiyüzlü bir istek olur. Ancak, kodu anlamalarına yardımcı olabiliriz.

15 dakika boyunca birlikte çalıştığınız tasarımcının yanında oturun ve onlara bir öğenin özelliklerinin doğru olup olmadığını ve bunları nasıl değiştireceklerini kendi kendilerine nasıl görebileceklerini öğretin. Firefox Page Inspector'ı bunun için son derece kullanıcı dostu buluyorum.

Günümüzde mizanpajları görselleştirmek, CSS animasyonlarında hata ayıklamak ve tipografide ince ayar yapmak bir zevk. Onlara keşfetmeleri için Codepen gibi kullanıma hazır bir kod oyun alanı gösterin. Düzen paradigmasının nasıl çalıştığını anlamak için tüm CSS özelliklerini bilmeleri gerekmez. Ancak, günlük işlerini güçlendirmek için öğelerin nasıl oluşturulduğunu ve davrandıklarını bilmeleri gerekir.

Tasarımcıları Geliştirme Sürecine Dahil Edin

Tasarımcıları stand-up toplantısında size katılmaya, KG sürecinin bir parçası olmaya ve uygulamalarınızda görsel ayrıntıları iyileştirirken sizinle birlikte oturmaya davet edin. Bu, web'in kısıtlamalarını anlamalarını sağlayacak ve çok geçmeden bir özelliğin uygulanmasının neden zaman aldığını anlayacaklardır.

Tasarımcılardan Tasarım Süreçlerine Sizi Dahil Etmelerini İsteyin

“Bir şeyleri güzelleştirmekten” çok daha fazlasını yaptıklarını anlayacaksınız. Araştırma süreci ve kullanıcı testinin nasıl yapıldığı hakkında daha fazla bilgi edineceksiniz. Size gösterdikleri her tasarım önerisi için daha önce birkaç başka çalışmanın çıkarıldığını keşfedeceksiniz. Tasarımcılar bir değişiklik talep ettiğinde, bunun nedenini sorun, böylece alınan kararlar hakkında daha fazla bilgi edinebilirsiniz . Sonunda, beyaz boşluk ve hizalamalar konusunda neden seçici olduklarını anlamaya başlayacaksınız ve umarım yakında siz de öyle olacaksınız!

Ön uç geliştirmeyi tasarım sürecinin temel bir parçası ve tasarımı da geliştirme sürecinin temel bir parçası olarak ele almayı çok önemli buluyorum. Herkesin tasarım ve geliştirme döngüsüne dahil olma şansına sahip olduğu bir zihniyeti savunmak, hepimizin birbirimizin zorluklarını daha iyi anlamamıza ve aynı zamanda harika deneyimler yaratmamıza yardımcı olacaktır.

Farklı Araçlar Kullanabiliriz Ama Aynı Dili Konuşmalıyız

Artık birbirimizin iş akışını biraz daha iyi anlamaya başladığımıza göre, bir sonraki adıma geçme zamanı: aynı dili konuşmak.

Kod Düzenleyicinin Ötesine Bakmak

Çevrenize dikkat etmeye başladığınızda, sorunların üstesinden gelmek için daha donanımlı olacaksınız. İşi daha iyi tanıyın ve tasarımcıların söyleyeceklerini dinlemeye istekli olun. Bu sizi projeye daha zengin katkıları olan bir ekip üyesi yapacaktır. Uzmanlığımızın ötesindeki alanlarda işbirliği yapmak, anlamlı sohbetler ve karşılıklı güven yaratmanın anahtarıdır.

UI Sistemlerini Sözleşme Olarak Kullanmak

Tasarımcılardan tasarım sistemlerini sizinle paylaşmalarını isteyin (eğer kullanmıyorlarsa başlamak için asla geç değildir). Bu, sizi kullanılan renkleri elle seçme, kenar boşluklarını bulma veya bir metin stili tahmin etme zahmetinden kurtaracaktır. UI Sistemine olduğu kadar aşina olduğunuzdan emin olun.

Bileşen tabanlı konsepte zaten aşina olabilirsiniz. Ancak bazı tasarımcılar bunu sizin gibi algılamayabilir. Bileşenlerin kullanıcı arabirimlerini daha verimli oluşturmanıza nasıl yardımcı olabileceğini onlara gösterin. Bu zihniyeti yayın ve benzer ama eşit olmayan isimlere güle güle deyin: başlık vs kahraman, fiyat bilgisi vs fiyat seçici . Kullanıcı arabiriminin bir parçası (diğer bir deyişle 'bir bileşen') oluşturulduğunda, hem tasarım hem de kod dosyalarına yansıtılabilmesi için aynı adları kullanmaya çalışın . Ardından, birisi "Teklif daveti widget'ını değiştirmemiz gerekiyor" dediğinde, herkes tam olarak ne hakkında konuşulduğunu bilir.

Gerçeğin Gerçek Kaynağını Kabul Etmek

Kullanıcı arayüzü ilk olarak tasarım dosyalarında oluşturulsa da asıl gerçek kaynak geliştirme tarafındadır. Günün sonunda, insanların gerçekte gördüğü şey bu, değil mi? Bir tasarım güncellendiğinde, özellikle çok sayıda insanın dahil olduğu projelerde, geliştirme durumu hakkında bir not bırakmak iyi bir fikirdir. Bu numara, iletişimi sorunsuz tutmaya yardımcı olur, bu nedenle (siz dahil) kimse merak etmez: “ Bu, canlı sürümden farklı. Bu bir hata mı yoksa henüz falan uygulanmadı mı? ”

Borcu Kontrol Altında Tutmak

Yani, teknik borç hakkında her şeyi biliyorsunuz - geçmişte son teslim tarihini karşılamak için yaptığımız bir kısayol nedeniyle yeni bir şeyi uygulama maliyeti yüksek olduğunda olur. Aynısı tasarım tarafında da olabilir ve biz buna tasarım borcu diyoruz.

Bunu şöyle düşünebilirsiniz: UX ve UI tutarsızlığı ne kadar yüksekse, borç (teknik ve tasarım) o kadar yüksek olur. En yaygın tutarsızlıklardan biri, aynı eylemi temsil etmek için farklı öğelere sahip olmaktır. Bu nedenle kötü tasarım genellikle kötü koda yansır . Tasarım borcumuzu ciddiye almak hem tasarımcılar hem de geliştiriciler olarak hepimize düşüyor.

Erişilebilir Olmak Çirkin Olmak Gerektiği anlamına gelmez

Hem geliştiriciler hem de tasarımcılar olarak sonunda işimize erişilebilirliği getirmeye başladığımızı görmekten gerçekten memnunum. Ancak birçoğumuz hala erişilebilir ürünler tasarlamanın zor olduğunu veya becerilerimizi ve yaratıcılığımızı sınırladığını düşünüyoruz.

Sadece kendimiz için bir ürün yaratmadığımızı hatırlatmama izin verin. Ürünü sizden farklı şekillerde kullananlar da dahil olmak üzere tüm insanların kullanabileceği bir ürün yaratıyoruz. Mevcut kullanıcı akışlarını açık ve tutarlı tutarken bireysel öğelerin nasıl daha erişilebilir olabileceğini hesaba katın.

Örneğin, bir tasarımcı gelişmiş bir seçme girdisi yaratmanın gerçekten gerekli olduğuna inanıyorsa, yanlarında durun ve onu farklı yeteneklere sahip çok çeşitli insanlar tarafından kullanılmak üzere erişilebilir bir şekilde tasarlamak ve uygulamak için birlikte çalışın.

Tasarımcılara Değerli Geribildirim Vermek

Tasarımları incelerken soruların ortaya çıkması kaçınılmazdır. Ancak bu, tasarımcıların hatalarından veya iddialı fikirlerinden şikayet etmeye başlamanız için bir neden değil. Tasarımcılar sizi zihinsel olarak yönlendirmek için orada değiller, sadece işinizi yapmak için neye ihtiyacınız olduğunu her zaman sezgisel olarak bilmiyorlar. Gerçek şu ki, geçmişte siz de bu şeyleri bilmiyordunuz, bu yüzden sabırlı olun ve işbirliğini bir öğrenme yolu olarak benimseyin.

Geribildirim Ne Kadar Erken O Kadar İyi

Geri bildirim için zamanlama çok önemlidir. Geri bildirim iş akışı büyük ölçüde proje yapısına bağlıdır, dolayısıyla bunun için herkese uyan tek bir çözüm yoktur. Bununla birlikte, mümkün olduğunda, erken aşamalardan başlayarak , periyodik geri bildirim iş akışını hedeflememiz gerektiğine inanıyorum. Bu açık işbirliği zihniyetine sahip olmak, daha sonra beklenmedik büyük tekrarlar olasılığını azaltmanın yoludur. Tasarımcıya ilk geri bildiriminizi ne kadar geç verirseniz, gerektiğinde yeni bir yaklaşımı keşfetme maliyetinin o kadar yüksek olacağını unutmayın.

Soyut Fikirleri Basit Terimlerle Açıklayın

Performansın tasarımcıların önceki işleriyle ilgili bir endişe olmadığını söylediğimi hatırlıyor musunuz? Web için optimize edilmiş SVG'lerin nasıl oluşturulacağının farkında olmadıklarında çıldırmayın. Çok sayıda farklı yazı tipinin yüklenmesini gerektiren bir tasarımla karşılaştığınızda, onlara istek sayısını neden en aza indirmemiz gerektiğini, hatta belki Değişken Yazı Tiplerinden yararlanmamız gerektiğini açıklayın. Daha hızlı yüklemenin yanı sıra daha tutarlı bir kullanıcı deneyimi sağlar. Tasarımcılar öğrenmeye hevesli değilse, bir şeyi açıklarken çok fazla teknik terim kullanmaktan kaçının. Bunu iletişim becerilerinizi geliştirmek ve düşüncelerinizi netleştirmek için bir fırsat olarak görebilirsiniz.

Varsayımların Karara Dönüşmesine İzin Vermeyin

Bir tasarım spesifikasyonuyla ilgili bazı sorular, yalnızca kodda ellerimizi kirlettiğimizde ortaya çıkar. İşleri hızlandırmak için, varsayımlarımıza dayalı kararlar verme konusunda kendimizi cazip hissedebiliriz. Lütfen, yapma. Bir varsayımı karara çevirdiğiniz her seferde, tasarım ekibinin kullanıcı arayüzünü uygulamak için size verdiği güveni riske atıyorsunuz. Ne zaman şüpheye düşseniz, uzanın ve şüphelerinizi netleştirin . Bu onlara nihai sonucu onlar kadar önemsediğinizi gösterecektir.

Çözümleri Kendi Başınıza Yapmayın

Sizden çok zor bir tasarımı uygulamanız istendiğinde “İmkansız” demeyin ya da bunun ucuz bir alternatif versiyonunu kendi başınıza uygulamaya başlayın. Bu, tasarımlarının beklendiği gibi uygulanmadığını gördüklerinde tasarım ekibiyle hemen sürtüşmeye neden olur. Öfkeyle tepki verebilir veya hiçbir şey söylemeyebilirler, ancak kendilerini mağlup veya hüsrana uğramış hissederler. Onlara bir şeyin neden mümkün olmadığını basit terimlerle açıklarsak ve alternatif yaklaşımlar önerirsek, bunların hepsi önlenebilir. Dogmatik davranışlardan kaçının ve yeni bir çözüm üzerinde işbirliğine açık olun .

Onlara Zarif Bozulma ve Aşamalı İyileştirme teknikleri hakkında bilgi verin ve birlikte ideal bir çözüm ve bir geri dönüş çözümü oluşturun. Örneğin, bir düzeni flexbox'tan CSS Grid'e geliştirebiliriz. Bu, bir özelliğin temel amacına saygı duymamızı ve aynı zamanda web teknolojilerinden en iyi şekilde yararlanmamızı sağlar.

Animasyonlar söz konusu olduğunda, gerçekçi olalım: derinlerde, bir sonraki wow animasyonunu uygulamak için tasarımcılar kadar onu oluşturmaktan heyecan duyuyorsunuz. Bizimle onlar arasındaki fark, web'in kısıtlamalarının daha fazla farkında olmamızdır. Ancak, bunun kendi becerilerinizi sınırlamasına izin vermeyin! Web hızla gelişiyor, bu yüzden bunu lehimize kullanmalıyız.

Bir dahaki sefere bir prototipi hayata geçirmeniz istendiğinde, onu önceden reddetmemeye çalışın ya da hepsini kendiniz yapın. Kendinizi zorlamak için bir fırsat olarak görün. Animasyonlar, web geliştirmenin en seçici bölümlerinden biridir, bu nedenle tasarımcınızla yüz yüze veya özel bir senkronize bağlantı paylaşarak her ana kareyi hassaslaştırdığınızdan emin olun.

İdeal Durumun Ötesini Düşünün — Birlikte

Olay şu: Her şey seninle ilgili değil. Tasarımcıların zorluklarından biri, kullanıcılarını gerçekten anlamak ve tasarımları Ürün Yöneticisine satmak için en çekici şekilde sunmaktır. Bazen ideal durumun ötesinde olanı unuturlar ve geliştiriciler de unutur.

Bu boşlukların oluşmasını önlemeye yardımcı olmak için, senaryo gereksinimlerini tasarımcılarla uyumlu hale getirin:

• En kötü durum senaryosu
  En kötü olasılıkların gerçekleştiği bir senaryo. Bu, tasarımcıların sabit içeriğe hayır demesine ve akıcı olmasına yardımcı olur. Başlık 60 karakterden fazlaysa veya liste çok uzunsa ne olur? Aynısı tam tersi, boş senaryo için de geçerlidir. Liste boş olduğunda kullanıcı ne yapmalıdır?
• etkileşim durumları
  Tarayıcı, gezinmekten ve etrafta tıklamaktan daha fazlasıdır. Bir grup durum vardır: varsayılan, vurgulu, odak, etkin, devre dışı, hata… ve bazıları aynı anda gerçekleşebilir. Onlara gereken ilgiyi gösterelim.
• yükleme durumu
  Yerel olarak bir şeyler inşa ederken, taklitler kullanabilir ve işlerin yüklenmesinin gerçekten zaman aldığını unutabiliriz. Tasarımcıların da bu olasılığı bilmesini sağlayın ve onlara, insanların bir şeylerin yüklenmesinin o kadar uzun sürmediğini algılamasını sağlamanın yollarını gösterin.

Tüm bu senaryoları dikkate almak, geliştirme aşamasında ileri geri gitmek için size çok zaman kazandıracaktır.

Not : Scott Hurff tarafından, bizi erişilebilir bir ürüne bir adım daha yaklaştıracak kötü kullanıcı arayüzlerinin nasıl düzeltileceği hakkında harika bir makale var.

Değişiklik İsteklerini Kabul Et

Geliştiricilerin, birisinin kodlarında bir hata bulması konusunda çok mutlu olmadıkları bilinir - özellikle de bu bir tasarımcı tarafından bildirilen bir tasarım hatası olduğunda. Etrafında çok fazla mem var, ancak bu tasarım hataları gelişigüzel bir şekilde göz ardı edildiğinde, bu hataların hem deneyimin kalitesini hem de ilişkinizi nasıl bileşik bir şekilde çürütebileceğini hiç düşündünüz mü? Yavaş yavaş olur, neredeyse uykuya dalmak gibi. Parça parça, sonra birden. Tasarımcılar, kayıtsızlık ve kızgınlık oluşup hiçbir şey söylenmeyene kadar “ Bu sadece küçük bir ayrıntı ” diyerek başlayabilir. Hasar o zaman zaten yapılmıştır.

Bu durum iki yönlüdür: hem yaşıtlarınıza hem de işinize. Bunun olmasına izin verme. Tepkinizi neyin renklendirdiği üzerinde çalışın. Bir tasarımcının 'seçici' olması sakıncalı olabilir, ancak aynı zamanda bir mühendisin dikkat ve coşkunun sığ yorumu olabilir. Biri size uygulamanızın (henüz) mükemmel olmadığını söylediğinde, egonuzu bir kenara koyun ve onlara nihai sonucu iyileştirmedeki sıkı çalışmalarını nasıl tanıdığınızı gösterin.

Arada Bir Kayıttan Çıkın

Hepimizin yerine getirmesi gereken görevleri ve bitirmesi gereken yol haritaları var. Ancak, en iyi işlerden bazıları kayıt dışı olur. YAPILACAKLAR panosuna giriş yapılmayacak ve sorun değil. Bir uyum içinde olduğunuz bir tasarımcı bulursanız, onların çalışma alanına gizlice girin ve birlikte yeni deneyler keşfedin. Oradan ne gelebileceğini asla bilemezsin!

Çözüm

Tasarım ekibinden öğrenmeye istekli olduğunuzda, aynı zamanda farklı düşünme yollarını da öğreniyorsunuz. Gözünüzü yeni deneyimler yaratmak için incelerken, diğer alanlarla işbirliği zihniyetinizi deneyiminizden çıkaracaksınız. Yardım etmek için orada olun ve öğrenmeye açık olun, çünkü bizi daha iyi yapan şey paylaşmaktır.

Bu makale, birçok harika insanın geri bildirimi olmadan mümkün olmazdı. Tasarımcılar ve geliştiriciler arasındaki yanlış anlamalar hakkında dengeli bir bakış açısını paylaşmama yardım ettikleri için tasarımcı Jasmine Meijer ve Margarida Botelho'ya minnettarım.

SmashingMag ile İlgili Okuma :

• Mason Gentry'den "Geliştiriciler İçin Tasarım"
• Rachel Andrew tarafından “Birlikte Çalışmak: Tasarımcılar ve Geliştiriciler Daha İyi Projeler Yaratmak İçin Nasıl İletişim Kurabilir”
• Stefan Kaltenegger tarafından “Ön Uç Geliştiriciler Tasarımcılar ve Geliştiriciler Arasındaki Boşluğu Kapatmaya Nasıl Yardımcı Olabilir”
• “Web Tasarımcıları ve Geliştiricileri Hangi Podcast'leri Dinlemeli?” tarafından Ricky Onsman