Geliştiriciler Kodun “Sahipliği”, O halde Tasarımcıların Deneyimin “Sahipliği” Olmamalı mı?

Hepimiz oradaydık. İş gereksinimlerini toplamak, karmaşık kullanıcı yolculukları üzerinde çalışmak, hassas arayüz öğeleri hazırlamak ve bunları temsili bir kullanıcı örneği üzerinde test etmek için aylar harcadınız ve yalnızca istenen deneyime çok az benzerlik gösteren nihai bir ürün gördünüz.

Belki de organizasyonun hazır olmadığına dair inancınıza rağmen daha güçlü olmalı ve çevik bir yaklaşımda ısrar etmeliydiniz? Belki de geliştiricilerin beş farklı atlıkarınca varyasyonu oluşturmak yerine modüler kod kitaplığınızı kullanmasını sağlayarak kalıp portföylerinizle daha iyi bir iş çıkarmış olmalısınız. Veya belki de her gün geliştirme ekibinin yanında oturup tasarladığınız şeyin gerçekten gerçekleştiğinden emin olmalısınız.

SmashingMag'de Daha Fazla Okuma :

• Neden Geliştiricinizi Tasarım Sürecine Dahil Etmelisiniz?
• Duyarlı Tasarımda Ekip İşbirliği ve Verimlilik Boşluklarını Kapatma
• Nice Oynayan Tasarımcılar ve Geliştiriciler
• Geliştiricilerle Etkili İletişim Nasıl Yapılır?

Bunun yerine, tüm incelikleri ortadan kaldırılmış bir UI öğeleri karmaşası ile kalıyorsunuz. Geçişleri doğru bir şekilde elde etmek için günlerce çalıştığınızı, yalnızca varsayılan bir animasyon kitaplığına düşmeleri için çalıştığınızı göremediler mi? Ve bu ekstra kontrol adımı nereden geldi? Bahse girerim pazarlama bunu son dakikada attı. Entegrasyonun zor olacağını ve tavizler verilmesi gerektiğini biliyordunuz, ancak bizim burada teknik ekibin değil, kullanıcıların hayatını kolaylaştırmamız gerekiyor.

Tabii ki, sitenin bu şekilde olmasının birçok iyi nedeni var. Projenin farklı bölümlerinde çalışan farklı becerilere sahip farklı ekipler, geliştirme döngüsünü kısaltan bir dizi son dakika değişikliği ve bir dizi teknik zorluk. Yine de, geliştirme ekibi neden gelip UI değişiklikleri hakkında tavsiyenizi isteyemedi? Kodlarıyla uğraşmıyorsunuz, o zaman neden tasarımlarınızı değiştirmek zorundalar? Özellikle iş etkisinin çok büyük olabileceği durumlarda! Sadece köşeyi döndünüz ve az önce sorsalardı yardım etmekten mutlu olurdunuz.

Yukarıdaki hikaye kurgu olsa da, şirket içi veya ajans tarafında olsun, tasarım dünyasının her köşesinden duyduğum bir duygu. Sabırlı bir geliştirme ekibi tarafından mahvedilen, özenle hazırlanmış bir deneyim.

Bu deneyim bana birkaç yıl önce bir ABD yerel haber kanalında gördüğüm bir haberi hatırlattı. Bir ilçe fuarı, eli bir kamyonette kalan son kişinin ödülü kazandığı bir dayanıklılık yarışması düzenliyordu. Tasarımın genellikle büyük bir "kamyona dokunma" oyunu gibi olduğunu düşünürüm, geliştirme ekibi her zaman yarışmanın sonunda anahtarlarla uzaklaşır. Bir tartışmadaki son söz gibi, siteyle iletişime geçecek son kişi tüm gücü elinde tutar ve sitenin nasıl çalıştığını veya nasıl göründüğünü belirleyebilir. Özellikle, belirli hedef deneyimin “teknik olarak mümkün” olmadığını iddia ederlerse, ki bu genellikle “gerçekten zor”, “Bunu bu şekilde yapmaktan rahatsız olamam” veya “Bunu yapmanın daha iyi bir yolu olduğunu düşünüyorum. bu yüzden geliştirici kartını çekeceğim ”.

Şimdi burada geliştiriciler hakkında haksız yere sert davrandığımı biliyorum ve öyle olmak istemedim. Kullanılabilirliği gerçekten önemseyen ve kullanıcı için en iyisini yapmak isteyen inanılmaz yetenekli teknoloji uzmanları var. Bununla birlikte, tasarımın kolay olduğu ve bu nedenle herkesin üzerinde fikir sahibi olabileceği bir inanç nedeniyle disiplinler arasında asimetrik bir saygı düzeyi varmış gibi hissedilirken, geliştirme zor ve sadece özel olarak başlatılanlar için. Bu nedenle, tasarımcılar herkesi tasarım sürecine dahil etmeye teşvik edilirken (bazen beklenir), çoğu zaman aynı lüksü alamazlar.

Dürüst olmak gerekirse, onları suçlamıyorum. Sonuçta, tehlikeli olacak kadar geliştirme biliyorum, bu yüzden veritabanı yapısı ve kod performansı hakkında fikrimi istersen aptal olurdun (büyük ölçüde performansın iyi bir şey olduğunu düşünüyorum). Sonra tekrar, geliştiricilerin ne zaman bir şeyleri karıştırdığını söyleyecek kadar bilgim var ve onlara imkansız olduğunu söyledikleri veya uygulanması aylar sürdüğünü söyledikleri bir şeyin çalışan bir prototipiyle geri dönmek her zaman eğlencelidir - ama ben dalıyorum.

Sorun şu ki, bence birçok geliştirici tasarım konusunda aynı konumda - sadece bunun farkında değiller. Bu nedenle, birkaç yıl önce bir konferansta duydukları bir şeye dayanarak bir arayüz öğesinde değişiklik yaptıklarında, önemli bir bağlamdan yoksun olabilirler. Belki de bu, daha önce test ettiğiniz ve düşük performans gösterdiği için indirim yaptığınız bir şeydi. Belki de erişilebilirlik gibi belirli bir nedenden dolayı bu öğeyi başka bir öğeye tercih ettiniz? Ya da belki de geliştiricilerin görüşleri, web'i ortalama bir Jo yerine süper kullanıcılar olarak nasıl deneyimlediklerini temel alarak yanlıştı.

Şimdi burada bir şeyi netleştirelim. Geliştiricilerin tasarıma ilgi göstermemesi veya tasarım sürecine girdi vermemesi gerektiğini söylemiyorum. İşlevler arası eşleştirmeye kesinlikle inanıyorum ve en iyi kullanılabilirlik çözümlerinden bazılarının teknoloji ekibinden çıktığını düşünüyorum. Ayrıca, çok sayıda disiplini kapsayan çok sayıda yetenekli insan var. Ancak, bir noktada deneyimin sahiplenilmesi gerekiyor ve bunun HTML dosyasını açıp “kamyona dokunan” son kişiye ait olması gerektiğini düşünmüyorum.

Öyleyse, iyi tasarımcılar beceriye saygı duyuyorsa ve harika geliştiricilerin masaya getirdiği deneyime saygı duyuyorsa, biraz pariteye ne dersiniz? Tasarımcılar, geliştiricilerin "koda sahip olmasından" memnunlarsa, neden benzer bir saygı gösterip tasarımcıların "deneyimi sahiplenmesine" izin vermiyorsunuz ?

Bunu yapmak oldukça basittir. Kendinizi bir şeyin neden belirli bir şekilde tasarlandığından emin olmadığınız bir durumda bulursanız ve daha iyi yapılabileceğini düşünüyorsanız, dalıp değişiklik yapmaya başlamayın . Benzer şekilde, teknik bir engelle karşılaşırsanız ve bir şeyi farklı bir şekilde tasarlamanın hayatınızı kolaylaştıracağını düşünüyorsanız, tasarımcınızla konuşun. Önerdiğiniz değişiklikleri kesinlikle kabul edebilirler ya da aynı sorunu çözmenin başka yollarını düşünmek isteyebilirler.

Sonuçta, işbirliği iki yönlüdür. Bu nedenle, tasarımcıların sürüm kontrol süreçlerinizin dışında, canlı sunucuda kodunuzu "optimize etmeye" başlamasını istemiyorsanız, lütfen aynısını tasarımlarına yapmayı bırakın.