Prensip, Heuristic, Pattern, Takım Sözleşmesi: Hangisi Neyi Çözer

Prensip, kullanılabilirlik heuristic'i, tasarım pattern'ı ve takım sözleşmesi dört ayrı araç. Pratikte dördü de "tasarım kuralı" diye tek torbaya atılıyor, sonra kimse hangi tartışmada hangisine bakacağını bilmiyor. Aşağıda her birinin cevapladığı soru, ve daha önemlisi cevaplamadığı soru var.

Prensip karar verdirmiyorsa prensip değil

Bir prensibin tek işi var: iki makul seçenek arasında kaldığında hangisini seçeceğini söylemek. "Kullanıcı odaklı tasarım yaparız" bunu yapmaz, çünkü tersini savunan bir ekip yok. "Kullanıcı hedeflerini ticari kısıtların önünde tutarız" yapar, çünkü tersi de savunulabilir bir pozisyon ve birçok ekip bilerek onu seçiyor.

Prensip taslaklarını genelde tersini yazarak ayıklarım. Tersi hiçbir ekibin ağzına almayacağı bir cümleyse, elimde prensip değil poster yazısı var. Beş tane sağlam prensip, on iki tane süslü başlıktan fazla iş görür.

Heuristic listesi masa başı denetimidir, kullanıcı testi değildir

Sistem durumunun görünürlüğü, kullanıcıya kontrol verme, tutarlılık, hata önleme: bunlar Nielsen'in on kullanılabilirlik heuristic'i olarak derli toplu duruyor, yeniden icat etmeye gerek yok. Tasarıma zımbalanacak bir onay listesi değil, bir denetim protokolü olarak kullan.

İki pratik nokta. Birincisi, tek kişinin yaptığı heuristic denetimi az bulur: Nielsen'in kendi ölçümünde tek değerlendirici sorunların üçte biri civarını yakalıyor, üç ila beş kişi birlikte dörtte üçüne çıkıyor. Tek uzmanın raporunu "arayüz denetlendi" diye kaydetmek, işin üçte birini kaydetmek demek. İkincisi, heuristic denetimi kuralın ihlal edildiğini söyler, kullanıcının görevi tamamlayıp tamamlamadığını söylemez. Bu yüzden sırası şu: denetimi testten önce yap, masa başından görülebilecek hataları temizle, kullanıcının saatini gerçek sorulara harca.

Pattern kataloğunun bakımı kodda yapılır

Ekmek kırıntısı navigasyonu, sayfalama, form doğrulama, ilerleme göstergesi. Pattern'ın değeri çözümün kendisinde değil, aynı sorunu her ekranda yeniden tartışmamakta.

Katalog yazarken iki bölüm çoğu zaman eksik kalıyor: pattern'ın nerede kullanılmayacağı, ve bileşen kütüphanesindeki karşılığı. İlki eksikse katalog tavsiye olmaktan çıkıp zorunluluğa dönüşür, ekipler uymadıkları her yerde savunmaya geçer. İkincisi eksikse katalog yavaşça yalana dönüşür: dokümanda duran ama kütüphanede olmayan her pattern, birisinin her seferinde elle yazacağı bir vaattir, ve üç ekran sonra üç farklı sayfalama davranışı çıkar. Pattern kaydının içine bileşen adını ve sürümünü yaz. Karşılığı yoksa durumu "önerilen" değil "planlanan" olarak işaretle.

Takım sözleşmesi kısa olmalı, yoksa okunmaz

Sözleşmenin işi değer beyanı yapmak değil, tıkandığınız anı çözmek. İçinde şunlar bulunsun: eşitlik bozulduğunda kararı kimin verdiği, geri bildirimin hangi kanalda ve ne kadar sürede verildiği, kararın nereye yazıldığı.

Son maddesi en çok atlanan ve en pahalıya patlayan madde. Kararı tarihiyle ve gerekçesiyle yazmazsanız, aynı tartışma üç ay sonra sıfırdan açılır, hem de bu kez kimse ilk gerekçeyi hatırlamadığı için. Uzaktan çalışan ekiplerde bu üç ay birkaç haftaya iniyor.

Dördü aynı anda kurulmaz

Hangi katmanın hangi soruyu cevapladığı netleşince sıra da netleşiyor:

Katman	Cevapladığı soru
Takım sözleşmesi	Anlaşamadığımızda ne yapıyoruz?
Prensipler	İki iyi seçenek arasında hangisini seçiyoruz?
Heuristic'ler	Bu ekran bilinen hatalardan hangisini yapıyor?
Pattern'lar	Bu sorunu daha önce nasıl çözdük?

Sıfırdan başlıyorsan prensiplerle değil pattern'larla başla. Ürün ortada yokken yazılan prensipler soyut kalıyor ve altı ay sonra kimse onlara bakmıyor; pattern kataloğu ise ilk haftadan iş görür. Prensipler, yeterince pattern biriktikten sonra zaten kendilerini gösteriyor: tekrar eden kararların arkasındaki ortak gerekçeyi yazıya geçirmek kalıyor.