Tasarımda Kontrol Listeleri: Hangi Maddeler Gerçekten İş Görür

Kontrol listesi tasarımda unutmaya karşı bir sigortadır, karar kalitesine karşı değil. Bu ayrımı kurmadan yazılan listeler işaretlemesi kolay ama hiçbir şeyi garanti etmeyen maddelerle dolar: son üründen memnun muyum, tasarım tutarlı mı. İyi bir madde ise tek bir yere bakıp yanıtlayabileceğiniz türdendir.

Liste hangi hatayı yakalar

Tasarım sürecinde iki ayrı hata sınıfı var. Birincisi atlama: yapılması gerektiğini bildiğiniz bir adımı, işin yoğunluğunda ya da sıralama karıştığı için yapmamak. İkincisi ise yargı hatası: adımı yaptınız, ama yanlış kararı verdiniz. Kontrol listesi yalnızca birinciye çare olur.

Listelerin havacılıktan ve ameliyathaneden yayılmasının nedeni de bu. Oralarda sorun pilotun uçağı tanımaması değildi, herkesin bildiği bir adımın baskı altında atlanmasıydı. Aynı mantık tasarıma taşındığında listeden beklenmesi gereken şey netleşir: size iyi bir ekran çizdirmez, çizdiğiniz ekranın yarım kalmadığını gösterir.

Bu yüzden "yaratıcılığı öldürüyor" itirazı çoğu zaman yanlış yere atılıyor. Liste keşif aşamasında değil, geçiş noktalarında durur: geliştirmeye devretmeden önce, teste vermeden önce, yayına almadan önce.

İyi maddenin tek ölçütü: doğrulanabilirlik

Bir maddeyi listeye almadan önce şunu deneyin: aynı maddeyi ekipten iki kişiye sorun, aynı yanıtı verirler mi? "Son üründen içten şekilde memnun muyum?" sorusu bu testi geçemez. Kimse projeyi teslim ederken bu soruya hayır demez, dese bile karşılığında ne yapılacağı belli değildir. "Tasarımın tutarlılığını kontrol ettim mi?" de aynı şekilde havada kalır, çünkü neyin kontrol edildiği tanımsızdır.

Doğrulanabilir maddeler bunun tam tersi biçimde durur:

• Boş durum ekranı tasarlandı mı?
• Hata mesajlarının metni yazıldı mı, yoksa hâlâ "bir sorun oluştu" mu diyor?
• Formdaki tüm alanlar klavyeyle sırayla dolaşılabiliyor mu?
• En uzun içerik, en uzun kullanıcı adı, en kalabalık liste görüldü mü?
• Yükleniyor durumu için bir şey çizildi mi?

Bunların hepsi bakılıp yanıtlanabilir. Bir projede listeye boş durum ekranını hiç yazmamıştık, canlıya çıktıktan sonra gelen ilk destek talebi tam oradan geldi. Bu tür maddelerin ortak yanı, hatanın tasarımcının hayal gücünde değil, ürünün az uğranan köşelerinde birikmesi.

İlkeler listeye kendiliğinden dönüşmez

ISO 9241-210, kullanıcı odaklı tasarımı altı ilkeye bağlar:

• Tasarım; kullanıcıların, görevlerin ve ortamların açık biçimde anlaşılmasına dayanır.
• Kullanıcılar sürecin tamamına dahil edilir.
• Tasarım, kullanıcı testleriyle yönlendirilir.
• Süreç tekrarlamalıdır.
• Bütünsel kullanıcı deneyimi gözetilir.
• Ekip çok disiplinlidir.

Bu maddeler bir kontrol listesi değil, listeyi üretecek çerçeve. "Kullanıcılar sürece dahil edildi mi?" diye sorarsanız yanıt her projede evettir, çünkü bir toplantıda bir kullanıcının adının geçmesi bile evet saydırır. Çerçeveyi projeye çevirmek gerekiyor: kaç kişiyle konuşuldu, hangi tarihte, hangi ekran üzerinde, çıkan not nereye yazıldı. İlke soyut kaldığı sürece listede yer kaplar, iş görmez.

Listeyi kısa tutmanın nedeni

Uzun liste, işaretleme törenine dönüşür. Otuz maddelik bir dosyayı teslim gününde açan kimse maddeleri gerçekten kontrol etmez, satırları aşağı doğru tarar. Yedi sekiz maddeyle sınırlı, projeye özel bir liste, kapsamlı olduğunu iddia eden uzun bir şablondan daha çok hata yakalar.

Sezgisel çalışmayı seven tasarımcının listeye ihtiyacı yok sanılır, oysa ihtiyaç aynı, yeri farklı. Süreci serbest bırakın, ama işi elden çıkarmadan önce durup bakın. Listenin değeri, tasarım yaparken değil, tasarımı bitirdiğinizi düşündüğünüz anda ortaya çıkar.