UX Dokümantasyonu: Neyi Saklamalı, Neyi Arşive Atmalı
Bir UX projesinde belge üretmek kolay. Zor olan, altı ay sonra o klasörü açan birinin hangi dosyanın hâlâ geçerli olduğunu anlaması. Dokümantasyon düzenleri çoğunlukla belge eksikliğinden çökmez; kimsenin bakmadığı ama herkesin doğru sandığı belgelerden çöker.
Asıl risk, eski belgenin güvenilir görünmesi
Birinci turda çizilmiş bir wireframe düşünün. İkinci turda ekran baştan kurgulandı, ama eski dosya klasörde duruyor. Kimse silmedi, çünkü silmek sorumluluk almak demek. Aradan zaman geçince yeni katılan bir geliştirici o dosyayı bulup uygulamaya başlıyor ve hatanın nereden geldiğini kimse çözemiyor.
Bu yüzden dokümantasyon disiplininin ilk kuralı yedekleme ya da adlandırma değil: geçerliliğini yitiren belgeyi aynı gün arşive taşımak. Arşivlemek silmekten psikolojik olarak çok daha ucuz, çünkü geri dönülebilir. Ekibe "bunu sil" demek yerine "arşive at" demek, aynı işi itirazsız yaptırır.
Dosya adı küçük bir veritabanıdır, bakımı elle yapılır
Yaygın tavsiye şudur: dosya adına sahip, tarih, belge türü ve versiyon yaz. UXteam_20240618_wireframe_v01.pdf gibi. Kulağa düzenli geliyor, ama bu şemadaki dört alanın en az ikisini depolama sisteminiz zaten tutuyor. Kim yükledi, ne zaman değişti bilgisi Drive'da da, Figma'da da, herhangi bir panelde de kayıtlı. Dosya adına kopyaladığınız an ikinci bir gerçeklik yaratmış oluyorsunuz ve bu ikisi ilk düzenlemede birbirinden ayrılıyor: dosyanın içeriği Ağustos'ta güncelleniyor, adındaki tarih Haziran'da kalıyor.
Versiyon numarası da aynı tuzağa düşüyor. Sürüm geçmişi tutan bir araçta v01, v02 yazmak gereksiz; tutmayan bir yerde ise zorunlu. Karar noktası bu. Dosyayı Figma'da ya da sürüm geçmişli bir bulut klasöründe saklıyorsanız versiyonu adına yazmayın, çünkü kimse v03'ü yüklerken v02'yi silmiyor ve klasörde beş kopya birikiyor. Sürüm geçmişi olmayan bir yere, mesela e-posta ekine ya da düz bir FTP dizinine koyuyorsanız numara vermek şart.
Geriye dosya adına gerçekten yazılması gereken iki bilgi kalıyor: belgenin hangi tura ait olduğu ve ne tür bir belge olduğu. tur02_kullanilabilirlik-testi.pdf, ilk örnekteki kadar bilgi taşır ve yalanlanma ihtimali yoktur.
Klasör ağacını kategoriye göre değil, tura göre kurun
Neredeyse her rehber aynı ağacı öneriyor: Araştırma, Tasarım, Geri Bildirim, Test, Final, Arşiv. Bu yapı projenin bir kez baştan sona akacağını varsayar. Gerçekte UX işi tur tur ilerler; ikinci turun test sonucu "Test" klasörüne düştüğünde birinci turunkiyle yan yana durur ve hangi tasarıma ait olduğunu ancak dosya adından çıkarabilirsiniz. Kategori tabanlı ağaç, en çok ihtiyaç duyduğunuz bilgiyi, yani zaman sırasını, dosya adına sürgün eder.
Tersi daha iyi çalışıyor. Üst düzeyde tur, altında kategori:
tur-01-kesif/ arastirma/ tasarim/ test/ tur-02-prototip/ arastirma/ tasarim/ test/ arsiv/
Bu düzende bir turu kapatmak tek bir klasörü taşımak demektir. Kategori tabanlı ağaçta aynı iş için altı klasörü tek tek gezmeniz gerekir, ki kimse gezmez.
İstisnası var: tur kavramı olmayan, sürekli akan ürün ekipleri. Orada tur yerine çeyrek ya da ay klasörü kullanmak aynı işi görür. Belirleyici olan takvim değil, ekibin doğal olarak "bitti" dediği an.
Yetkilendirmede yanlış varsayılan gölge kopya üretir
Erişim kontrolünde iki uç görüyorum. Ya her şey herkese açık, ya da her şey kilitli ve talep üzerine açılıyor. İkincisi kâğıt üzerinde güvenli görünür, pratikte tam tersini yapar: belgeye erişemeyen kişi ekran görüntüsü alır, Slack'e atar, birisi de indirip masaüstünde tutar. Kısıtlama arttıkça sistemin dışında dolaşan kopya sayısı artar ve o kopyalar hiçbir erişim kaydında görünmez.
Makul ayrım kişisel veriden geçiyor. Araştırma özetleri, tasarım dosyaları, test raporları ekibe açık olsun. Kilit yalnızca ham kayıtlara, yani kullanıcı görüşme videolarına, transkriptlere ve katılımcı iletişim bilgilerine gerekiyor. Bunlar zaten hukuki olarak da ayrı muamele istiyor.
Değişiklik kayıtları için de aynı şey geçerli: log tutmak tek başına bir güvenlik önlemi değil. Kimsenin okumadığı log, yalnızca olay çıktıktan sonra işe yarar. Ayda bir kez beş dakika bakılmayacaksa, kurmanın maliyetine değmiyor.
Temizliği takvime değil, işin ritmine bağlayın
"Dönemsel dokümantasyon temizliği yapın" tavsiyesi doğru ama tanımsız olduğu için hiç uygulanmıyor. Somutlaştırmanın en kolay yolu, temizliği bir turun kapanışına yapıştırmak. Tur bitti, otuz dakika ayırın, tek iş: o turun belgelerini arşive taşımak ve geçerli belgelerin listesini güncellemek.
O liste, üstteki bütün klasör tartışmasından daha çok işe yarar. Tek sayfalık, on satırlık, "şu an geçerli olan" başlıklı bir dizin: mevcut tasarım dosyası nerede, son test raporu hangisi, karar kayıtları hangi belgede. Ekibe yeni katılan biri klasör ağacını öğrenmek zorunda kalmaz, bu sayfayı okur. Ağaç yapısı belgeleri yerleştirmek için vardır; bu sayfa onları bulmak için.
Kaynak