UX Tasarımcısı Kod Yazmalı mı? Yanlış Kurulmuş Bir Soru
UX tasarımcısı kod yazmalı mı sorusu genelde iki uçtan cevaplanıyor: ya herkes kod öğrenmeli, ya da tasarımcının işi bu değil. İki cevap da sorunun kendisinin yanlış kurulmuş olmasından besleniyor. Asıl mesele kod yazabilmek değil, verilen tasarım kararının uygulamaya ne mal olacağını tahmin edebilmek.
Ölçüt kod değil, maliyet tahmini
Bir ekranda "buraya canlı arama koyalım" cümlesi kuruluyor. Bu cümlenin arkasında ne olduğunu bilen tasarımcıyla bilmeyen tasarımcı arasındaki fark, sözdizimi bilgisi değil. Her tuşa basıldığında sunucuya istek gitmesi, o isteğin iptal edilmesi gereken bir öncekiyle yarışması, boş sonuç durumunun ayrıca tasarlanması, yavaş bağlantıda ne görüneceği. Bunların hiçbiri kod yazmayı gerektirmiyor, hepsi kodun nasıl çalıştığını bilmeyi gerektiriyor.
Kod öğrenmenin tasarımcıya kazandırdığı şey de zaten bu tahmin yeteneği. Kod yazma becerisi onun yan ürünü, hedefi değil.
"Teknoloji değişiyor, öğrenmek boşa" itirazı
En sık duyulan karşı argüman bu: öğrendiğin dil birkaç yılda eskir. Doğru olduğu bir kısım var, ama yanlış katmanı işaret ediyor.
Eskiyen şey framework modası. Bir tasarımcının işine yarayan katman ise nerdeyse hiç değişmiyor: bir sayfanın nasıl yüklendiği, tarayıcının elemanları hangi sırayla yerleştirdiği, bir isteğin neden 200 ms değil 2 saniye sürdüğü. Kutu modeli yirmi yıl önce de aynıydı. Değişen, o kutuyu üreten kütüphanenin adı oldu (tasarımcının framework öğrenmesi gerektiği fikrini abartılı buluyorum).
Tünel görüş gerçek bir risk, ama sanıldığı yerde değil
Kod bilen tasarımcının "bu zor olur" deyip vazgeçmesi sık görülür. Yalnız burada bir ayrım var: zorluğu bilerek vazgeçmek ile bilmeden istemek arasında üçüncü bir yol da mümkün, maliyeti bilip yine de savunmak.
Pratikte tıkanma noktası genelde tasarımcının teknik bilgisi değil, o bilgiyi pazarlık masasında nasıl kullandığı. "Yapılamaz" cümlesini geliştiriciden duyup kabul eden tasarımcı, kod bilmediği için değil, sorunun hangi kısmının zor olduğunu soramadığı için geri adım atıyor. Kod bilgisi tam da bu soruyu sormaya yarıyor.
Kod yazmayan araçlar kısıtı ortadan kaldırmıyor
Bu tartışmada genelde şu teselli sunulur: artık sürükle bırak araçlar var, teknik bilgiye gerek kalmadı. Araçlar gerçekten iyileşti, ama kısıtı yok etmediler, yalnızca yerini değiştirdiler.
Kodda karşılaşacağın sınır en azından okunabilir bir sınır. Sayfa yavaşsa nedenini bulabilirsin, davranış istediğin gibi değilse değiştirebilirsin. Kapalı bir araçta ise sınır, aracın sana verdiği ayar setinin bittiği yer. Neden orada bittiğini göremezsin ve genişletemezsin. İkisinden hangisinin tasarımcıyı daha çok kısıtladığı en azından tartışmalı, öyle otomatik bir üstünlük yok.
Karar ekibin büyüklüğüne bakar
Tek başına ya da üç kişilik bir ekipte ürün çıkarıyorsan, HTML ve CSS seviyesinde bir bilgi doğrudan hız kazandırır. Prototipi kendi kurar, tartışmayı ekran görüntüsü üzerinden değil çalışan bir sayfa üzerinden yaparsın.
Ekip büyüdükçe denge kayar. Otuz kişilik bir üründe tasarımcının kendi kodunu yazması ekibin akışını bozar; orada değerli olan şey, geliştiriciyle aynı kavram setini paylaşmak. Bileşen nedir, durum nedir, bir alanın zorunluluğu nerede kontrol ediliyor. Bunlar için kod yazmak gerekmez, kodu okuyabilmek yeter.
Nereden başlanır
- Tarayıcının geliştirici araçları. Kendi tasarladığın sayfayı açıp elemanları kurcalamak, çoğu kurstan hızlı öğretir.
- HTML ve CSS. Erişilebilirlik kararlarının çoğu doğru etiketi seçmekle ilgili, bu da doğrudan tasarımın işi.
- Ağ sekmesi. Hangi isteğin ne kadar sürdüğünü görmek, "yükleniyor" durumunu tasarlarken tahmin yapmayı bırakmanı sağlar.
JavaScript ve framework tarafı bu listenin dışında kalıyor, çünkü tasarım kararlarının pek azı oraya dayanıyor.