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

UX Dokümantasyonunda Zor Olan Yazmak Değil, Güncel Tutmak

UX Belgeleri: Bakım Maliyeti ve Tek Kaynak İlkesi

UX belgelerinin çoğu yazıldığı hafta doğru, üçüncü ayda yanlıştır. Kimse yanlış olduğunu ilan etmez, çünkü bunu fark etmek için birinin dosyayı açması gerekir; dosyayı açan kişi de zaten oradaki bilgiye güvenmek için açmıştır. Asıl soru hangi belgeyi yazacağın değil, hangisini önümüzdeki altı ay boyunca güncel tutmayı göze aldığın.

Yazmak bir öğleden sonra, bakım proje boyu

Bir persona belgesini ya da akış diyagramını çıkarmak uzun sürmez. Yük sonra başlar: ürün değişir, ekran kaybolur, karar geri alınır, belge olduğu yerde kalır.

Peki bir belge tam olarak ne zaman zarar vermeye başlar? Bilgi eskidiği anda değil, o bilgiye dayanarak biri karar verdiği anda. Üç aydır kimsenin açmadığı eski bir doküman zararsızdır. Yeni gelen geliştiricinin açtığı aynı doküman iki günlük iş kaybıdır.

Bu yüzden belge sayısını varlık değil borç kalemi olarak görmek daha doğru. Her yeni dosya, ürün her değiştiğinde kontrol edilecek bir yer daha demek. Sürüm geçmişini belgenin ilk sayfasına elle tablo olarak yazmak da yaygın bir alışkanlık (bunu gereksiz buluyorum, dosyanın durduğu sistem o geçmişi zaten tutuyor).

Aynı bilgi iki yerdeyse biri yanlıştır

“Belgeyi hedef kitleye göre yaz” tavsiyesi kulağa doğru gelir, tek başına uygulandığında kopya üretir. Sponsora üç sayfalık özet, geliştiriciye ayrıntılı akış, ajansa sunum. Üçünde de aynı kullanıcı akışı anlatılır. Akış değiştiğinde biri güncellenir, diğer ikisi eski haliyle dolaşımda kalır.

Çözüm belge sayısını kısmak değil, aynı bilgiyi tek yerde tutmak. Akışın bir kanonik hali olsun, diğer belgeler onu tekrar anlatmasın, ona bağlansın. Peki sponsor o bağlantıya tıklamazsa? Tıklamasına gerek kalmaması için özetin taşıdığı şey akışın kendisi değil, verilen karar ve gerekçesi olmalı. Karar nadiren değişir, akış sürekli değişir; ikisini aynı dosyaya koyarsan belge akış hızında eskir.

Bu gece silinse hangi karar askıda kalır?

Yazmadan önce sorulacak soru bu kadar. Cevap yoksa o belge bir karara değil, bir alışkanlığa hizmet ediyordur.

Soruyu geçen belgeler de birbirine benzemiyor. Kullanıcı testi raporu geçer: olmuş bir şeyin kaydıdır, tarihi vardır, eskimez, sadece yaşlanır. Altı ay önce sekiz kişinin o ekranda nerede takıldığı bugün de doğru. Persona tam ters yönde çalışır, çünkü bugünkü kullanıcıyı anlatma iddiasındadır; ürün ve kitle kaydıkça sessizce yanlışa döner ve kimse fark etmez.

Wireframe ile prototip ise çoğunlukla tek kullanımlık. Kararı verdirdikten sonra işlevleri biter. Arşivde kalacaklarsa “bu, X kararının alındığı andaki hal” notuyla kalmalı, güncel tasarım diye değil.

Bulunamayan belge yok sayılır

Dosya adı, klasör ağacından daha çok iş görür. İnsanlar belgeye gezinerek değil arayarak ulaşıyor, dolayısıyla adın içinde konunun geçmesi gerekiyor. “sunum-final-v3.pdf” hiçbir aramada çıkmaz.

PDF tercih edilecekse metin katmanı olan bir PDF olsun. Slaytların ekran görüntüsünden üretilmiş dosya ne aramada bulunur, ne ekran okuyucu tarafından okunur, ne de içinden bir cümle kopyalanabilir. Erişilebilirliği burada yalnızca engelli kullanıcı meselesine daraltmaya gerek yok: aranamayan belge herkes için yarı yarıya kayıp.

Kaynaklar