Ekipten Gelen Tasarım Önerileriyle Ne Yapmalı

Toplantının ortasında gelen “şu butonu yukarı alsak” önerisi, tasarımcının en hızlı savunmaya geçtiği andır. Oysa önerinin kendisi nadiren asıl meseledir; onu doğuran rahatsızlık asıl meseledir. İkisini ayırmadan verilen cevap ya gereksiz bir tartışma ya da huzur olsun diye kabul edilmiş kötü bir karar üretir.

Öneri bir cevaptır, soruyu bulmak sana kalır

Birisi “formu kısaltalım” dediğinde teşhisten çözüme geçişi kafasında çoktan yapmıştır ve sana genellikle yalnızca ikinci yarısı ulaşır. Arkada duran şey çoğu zaman şudur: iki müşteri telefonda formdan şikâyet etmiştir. Kısaltmak bir çözüm önerisi, şikâyet ise veri. Veriyi görmeden çözümü tartışmaya başlarsan tartışma zevk meselesine iner.

Öneriyi duyduğunda üç şeyi sormak çoğu zaman yetiyor:

• Bunu ilk ne zaman fark ettin?
• Kaç kişide gördün, yoksa tek bir olay mı?
• Şu anda insanlar bu durumu nasıl idare ediyor?

En çok işe yarayanı üçüncüsü. İnsanların bir eksiği idare etme biçimi, o eksiğin gerçekten can sıkıp sıkmadığını gösterir. Birisi bir alanı doldurmak için sekme değiştirip kendi kayıtlarına bakıyorsa problem gerçektir. Kimse hiçbir şey yapmıyorsa muhtemelen problem de yoktur. Öneriyi doğrudan test kuyruğuna almaktan çok, arkasındaki gözlemi sormayı daha güvenilir buluyorum: test, yanlış soruyu da aynı titizlikle ölçer ve sana temiz görünen bir sayı verir.

“Test ederiz” demenin sessiz maliyeti

Bir öneriye itiraz etmenin en kibar yolu onu ölçüme havale etmek. Peki ölçüm gerçekten mümkün mü? Dönüşüm oranı %3 olan bir akışta bu oranı %3,3'e çıkaracak bir farkı makul güvenle görebilmek için varyant başına elli bin civarı ziyaretçi gerekir. Haftada iki bin ziyaretçi alan bir sayfada bu, testin bir yıl sürmesi demek. Yani o sayfada “A/B testiyle bakarız” cümlesi aslında “bakmayacağız” anlamına gelir, ve bunu bir süre sonra söyleyen de dinleyen de fark eder.

Trafik yetmiyorsa geriye iki dürüst seçenek kalıyor. Öneri bir anlama problemine dokunuyorsa beş kişiyle yapılan bir kullanılabilirlik oturumu yeterince bilgi verir; butonun yeri insanları şaşırtıyor mu sorusunu cevaplamak için elli bin ziyaretçiye gerek yok. Öneri bir tercih meselesiyse karar verip gerekçeyi yazmak, olmayacak testi beklemekten daha az zarar verir.

Reddettiğin öneriyi bir yere yaz

Reddedilen öneriler geri gelir. Aynı fikir dört ay sonra başka bir toplantıda, çoğu zaman başka birinin ağzından önüne tekrar düşer; o an ilk seferde neden hayır dediğini hatırlamıyorsan tartışmayı baştan yaparsın. Bir satır yeterli: öneri, tarih, kimden geldiği, hangi gerekçeyle ertelendiği. Kaydın ikinci faydası da gerekçenin eskiyip eskimediğini görmek. Trafik artmış, o formu dolduran kitle değişmiş olabilir. Aynı öneriye bu kez evet demek tutarsızlık değil.

Hayır demek tartışma açmak zorunda değil

Bir öneriyi uygulamayacaksan gerekçeyi paylaşmak, teşekkür etmekten daha kıymetli. “Katkın için sağ ol” tek başına kapıyı kapatır; karşıdaki kişi fikrinin nereye gittiğini bilmez, bir sonrakini de getirmez. Neyi niçin tercih ettiğini söylediğinde ise ona itiraz edebileceği bir şey vermiş olursun. Bazen itiraz haklı çıkar.

Zor kısım, gerekçenin gerçekten gerekçe olması. “Tasarım diliyle uyumsuz” bir gerekçe değil, bir etiket. Uyumsuzluğun ne yarattığını söylemek gerekir: bu düğme burada dururken kullanıcı listeden çıkmadan kayıt siliyor, geri alma da yok.

Önerinin geldiği an, içeriğinden çok şey söyler

Aynı öneri eskiz aşamasında bir cümledir; geliştirme başladıktan sonra bir dal, bir koşul ve arkasından gelen bir bakım yükü. “Şunu seçenek olarak da ekleyelim” dendiğinde tasarıma tek bir ekran eklenir, kodda ise kalıcı bir çatallanma kalır ve o çatallanma bir daha silinmez. O yüzden geç gelen öneride sorulacak şey onun iyi olup olmadığı değil, üç hafta önce sorulmuş olsa neyin değişeceği.

Bunun çaresi daha sıkı bir onay süreci kurmak değil, öneriyi ucuzken davet etmek. Yarım bitmiş bir ekranı göstermek insanları konuşmaya çağırır; cilalı bir ekran ise onlara işin bittiğini söyler, itirazlar da tam bu yüzden geliştirmenin ortasında çıkar.