Konu Başlıkları
Yükleniyor...

Uzaktan Tasarımda Kararı Yazıya Dökmek

Uzaktan UX/UI Ekiplerinde Karar Kaydı ve Asenkron Kritik

Uzaktan çalışan bir tasarımcının asıl ürünü ekrandaki arayüz değil, o arayüzün neden öyle olduğuna dair kayıt. Ofiste bu kayıt konuşmayla tutuluyordu, kimse ayrı bir iş saymıyordu. Masalar dağılınca ortaya çıkan boşluk yetenek boşluğu değil, aktarım boşluğu.

Ofiste bedava olan şey uzaktan faturalı

Yan masadaki geliştiricinin “o bileşende böyle bir boşluk yok” demesi on saniye sürerdi. Aynı düzeltme uzaktan çalışırken ya bir toplantıya ya da iki gün sonra gelen bir yoruma dönüşüyor. Tek tek bakınca kayıp görünmüyor; ay sonunda kaç kararın geç düzeltildiğine bakınca görünüyor.

Peki ya hiç düzeltilmezse? Çoğu zaman olan bu. Tasarım olduğu gibi geçer, uygulamada bir yerde bozulur, kimse başa dönüp neden bozulduğunu sormaz.

Kararı yazmak tartışmayı bitirir

Karar kaydının işe yarayan hali kısadır: ne seçildi, hangi seçenek elendi, neden elendi. Üçüncü satırı olmayan kayıt üç ay sonra hiçbir şey anlatmaz, çünkü asıl merak edilen şey seçilen değil elenendir.

Faydası ekibe yeni katılan kişide görülür. Kayıt varsa kapanmış bir tartışmayı yeniden açmaz, okur ve devam eder. Yoksa aynı tartışma yılda iki kez, her seferinde sıfırdan yapılır.

Asenkron kritik, toplantının yazıya çevrilmiş hali değil

Ekrana genel yorum bırakmak (“biraz sıkışık durmuş”) asenkron ortamda karşılıksız kalır, çünkü karşı taraf hangi kararın sorgulandığını bilemez. Yorumu tek bir karara bağla: hangi öğe, hangi alternatife göre, neye bakarak daha kötü. Tasarımcı böyle bir yoruma cevap verebilir, genel izlenime veremez.

Öğretme kısmı işin yan ürünü değil

Eğitim odaklı tasarımcı rolü, Interaction Design Foundation'ın tarif ettiği biçimiyle, rehber ve şablon üretmek etrafında dönüyor. Zor tarafı içeriği yazmak değil, kuralı uygulanabilir hale getirmek.

“Boşlukları tutarlı kullanın” cümlesi kimseye bir şey yaptırmaz. “Kart içi dikey boşluk 16, kartlar arası 24” yaptırır. Aradaki fark yazarlık becerisi değil, kuralın ölçülebilir olup olmaması.

Devirde kaybolanlar

Ölçüyü Figma'da px olarak not etmek yerine bileşenin hangi boşluk değerine oturduğunu yaz; geliştirici zaten o değer kümesiyle çalışıyor, 18px'i en yakın komşusuna yuvarlamak zorunda kalmasın. Renk için de aynısı geçerli, ekrandan damlalıkla alınan kod hangi tona karşılık geliyorsa onu yaz.

Bir de kodda karşılığı olmayan vaatler var. “Geçiş anlık olsun” notu, veri yarım saniyede geliyorsa tasarım kararı değil temenni. Orada doğru hamle geçişi hızlandırmaya çalışmak değil, bekleme durumunu tasarlamak.