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

Asenkron Tasarım Eleştirisi: Yazılı Geri Bildirim Nasıl Yazılır

Yazılı Geri Bildirimde Gözlem, Üslup ve Biçim

Aynı odada olmayan bir ekipte geri bildirim yazıya dökülür ve orada kalır. Tonu da gerekçesi de sonradan okunabilir; kolaylığı burada, zorluğu da. Senkron bir toplantıda yanlış anlaşılan cümleyi on saniyede düzeltirsin, yazılı bir yorumda aynı düzeltme ertesi güne kalır. Yazılı tasarım eleştirisi üç ayrı katmanda kurulur: ne söylediğin, nasıl söylediğin, nasıl biçimlendirdiğin.

İçerik: gözlemle başla

Bir eleştiri gözlemle başladığında tartışmaya açık olur. "Bu iki buton biri ileri biri geri gibi duruyor, oysa diğer ekranlarda tek buton ve bir kapatma çarpısı var" cümlesi tasarımcıya nereye bakacağını söyler. "Butonlar kafa karıştırıcı" cümlesi söylemez.

Gözlemin ardından etkiyi yaz. Tutarsızlığın akışta neyi bozduğunu, hangi ekranda ne pahasına göründüğünü belirt. Bu kısım atlanınca geri bildirim bir zevk beyanına dönüşür ve karşı tarafın onu ciddiye alması için elinde sebep kalmaz.

Bir eleştiriyi "bence böyle daha iyi" diye bırakmam. Kod incelemesinde gerekçesiz bir değişiklik isteğini kabul etmiyorsam, tasarım dosyasında da etmem.

Soru mu sorulmalı, öneri mi yapılmalı

Açık uçlu soru genelde övülür: "Tüm ekranlarda aynı buton çifti olsa nasıl olur?" diye sorarsın, tasarımcı kendi çözümünü üretir. Doğru bir yaklaşım, ama her fazda değil.

Projenin başındaysan sor. Kurgu henüz oturmamıştır ve senin aklına gelmeyen bir çözüm çıkabilir. Teslime üç gün kala aynı soru iş değil kaygı üretir; orada doğrudan öneri yazmak daha saygılıdır. "Tüm ekranlarda ileri-geri çiftine geçelim" dediğinde karar hâlâ tasarımcının, ama seçenekleri baştan keşfetmek zorunda kalmaz.

Üslup: göndermeden önce oku

Yazılı geri bildirimin en büyük avantajı, gönderilmeden önce denetlenebilmesidir. Yazdıktan sonra bir kez daha oku ve tek soru sor: bu cümle işi mi hedefliyor, kişiyi mi? "Hizalama üç piksel kaymış" ile "hizalamayı yanlış yapmışsın" arasındaki fark küçük görünür. İkincisi karşı tarafı savunmaya geçirir ve altındaki on maddeyi de okunmaz hale getirir.

Ekipte farklı ülkelerden insanlar varsa imayla ya da espriyle yumuşatılmış eleştiri çoğu zaman hedefini bulmaz. Düz yaz.

Biçim: taranabilir olsun

Uzun bir yorum bloğu baştan sona okunmaz. Maddelere ayır ve ağırlığını işaretle. Renk ya da emojiyle önem sırası vermek basit bir yöntem, ama iyi çalışır: bloklayıcı 🟥, geliştirilebilir 🔶, olumlu 🟢, merak 🌀. Tasarımcı hangi maddeye önce bakacağını tek bakışta görür.

İyi giden şeyi de yaz, üstelik neden iyi olduğunu belirterek. Bu bir nezaket kuralı değil: hangi kararın korunması gerektiğini söylemezsen revizyonda o karar da gider.

Asenkronun asıl maliyeti tur sayısıdır

Toplantıda belirsiz bir cümle kurarsan karşındaki hemen sorar, iş on saniyede düzelir. Aynı belirsizliği yazıya koyduğunda tasarımcı sorusunu yazar, sen ertesi sabah görürsün, cevaplarsın, o öğleden sonra okur. Tek bir netleştirme turu bir günü yer; iki tur haftanın ortasını.

Bu yüzden asenkronda uzun yazmak zaman kaybı değil. Hangi bilgiyle konuştuğunu, projeyi tanıyıp tanımadığını baştan söyle. Eleştiriyi hazırlarken harcadığın beş fazladan dakika, karşı taraftaki bir günlük gecikmeyi satın alıyor.

Nereden başlanır

Hepsini birden düzeltmeye çalışma. Kendinde en zayıf gördüğün tek başlığı seç ve birkaç hafta yalnızca ona dikkat et. Gözlem yazmayı atlıyorsan her yorumu gözlemle başlatma alışkanlığı edin, ton sorunun varsa göndermeden önce okuma kuralını koy. Alışkanlık oturunca bir sonrakine geç.

Kaynak