UX Teslimatları: Hangi Belge Hangi Kararı Besler?
Bir UX projesinde üretilen belgelerin önemli bir kısmı tasarımı ilerletmek için değil, bir toplantıyı geçmek için hazırlanır. Ayrım basit: belge bir kararı besliyorsa teslimattır, beslemiyorsa sunum malzemesidir. Aşağıda yaygın UX teslimatlarının hangi soruyu yanıtladığı, hangisinin ne zaman gereksiz olduğu ve asıl maliyetin nerede biriktiği var.
Her belgeyi bir kararla eşleştirin
Teslimat seçimi listeden seçmekle başlamaz, cevabını bilmediğiniz bir soruyla başlar. Ortada bekleyen soru yoksa üretilen belge kimseyi bir yere götürmez, sadece klasörde yer kaplar.
| Belge | Yanıtladığı soru | Gereksiz olduğu durum |
|---|---|---|
| Affinity diagram | Ham gözlemler hangi temalarda toplanıyor? | Yirmi otuz not için not defteri yeterli |
| Analitik raporu | İnsanlar ürünü şu an nasıl kullanıyor? | Ürün henüz yayında değilse ölçecek bir şey yok |
| Journey map | Kullanıcı akışın neresinde düşüyor? | Akış tek ekrandan ibaretse |
| Persona | Kime, hangi kısıt altında tasarlıyoruz? | Arkasında görüşme yoksa |
| Wireframe | Ekranda ne var, hiyerarşi nasıl kuruluyor? | Mevcut bir ekranın küçük düzenlemesinde |
| Prototip | İnsan bu akışı tamamlayabiliyor mu? | Soru görsel değil, işlevselse ve kodda denenebiliyorsa |
| Tasarım sistemi ve stil rehberi | Aynı bileşen iki farklı yerde nasıl aynı davranacak? | Tek ekranlık, ömrü kısa üründe |
Çoğu projede bu satırlardan üçü dördü işi görür. Ekip büyüdükçe belirleyici olan belge sayısı değil, belgenin ekip içinde ne kadar hızlı dolaştığıdır.
Persona ve antipersona arasındaki fark
Persona, araştırmadan çıkan kısıtların tek sayfaya sıkıştırılmış halidir. Persona dosyasını tek başına tasarım gerekçesi saymam; arkasında görüşme kaydı ya da saha notu yoksa elinizdeki şey bir kullanıcı temsili değil, ekibin varsayım listesidir. Bir persona satırının yanına o satırı doğuran cümlenin kaynağını yazın, dosya bir anda tartışılabilir hale gelir.
Antipersona ise ürünü kötüye kullanacak kişiyi tarifler. Yazılım tarafındaki karşılığı kötüye kullanım senaryosudur: spam gönderen, formu otomatize eden, ücretsiz kotayı sömüren kullanıcı. Bu belgeyi tasarımcı yalnız başına yazmasın, geliştiriciyle birlikte yazsın; çünkü çıkan maddelerin çoğu arayüzde değil doğrulama katmanında çözülür.
Wireframe mi, prototip mi
Sorunuz "ne nerede duracak" ise wireframe yeterlidir ve gri kutularda kalması gerekir. Wireframe'i güzelleştirmeye başladığınız anda geri bildirim yerleşimden renge kayar, tartışmak istediğiniz konuyu kaybedersiniz.
Sorunuz "insan bunu yapabiliyor mu" ise wireframe cevap veremez, tıklanabilir bir akış gerekir. Prototipte sahte veri değil gerçeğe yakın veri kullanın: on iki karakterlik ürün adıyla test edilen liste ekranı, kırk karakterlik gerçek adlarla bozulur. Kullanılabilirlik raporunu da bulgu listesi olarak değil, karar listesi olarak yazın; her bulgunun altında ne değişeceği ve kimin değiştireceği yazmıyorsa rapor arşiv malzemesidir.
Sözlüğü kısa tutun
Terim sözlüğü, ekip içinde gerçekten tartışılan kelimeler için işe yarar. Kırk maddelik bir sözlük hazırlandığı hafta okunur, sonra kimse açmaz. On maddeyi geçmeyen, ekibin son üç ayda yanlış anladığı terimleri toplayan bir sayfa daha çok iş görür ve yeni gelen birinin ilk gününde okuyabileceği uzunluktadır. Sözlüğü teslimatların durduğu yerin dışında bir yerde tutmayın; ayrı yaşayan sözlük ilk ayda eskir.
Asıl maliyet üretmek değil, güncel tutmak
Bir belgenin maliyeti hazırlandığı gün bitmez. Altı aktif belgeniz ve iki haftada bir sürümünüz varsa yılda 26 sürüm, yani 150'nin üzerinde güncelleme fırsatı çıkar. Bunların çoğu atlanır ve atlandığında belge sessizce yanlışa döner. Eski bir journey map hiç olmamasından kötüdür, çünkü ekip ona hâlâ güveniyordur.
Uzun ömürlü kalan teslimatların ortak özelliği var: ürünün kendisinin tükettiği bir biçimde yaşıyorlar. Tasarım sistemindeki renk ve boşluk değerleri kodun okuduğu bir dosyadan geliyorsa güncel kalmak zorundadır, yanlış olursa arayüz bozulur ve hemen fark edilir. Aynı bilgi yalnızca bir sunum görselinde duruyorsa kimse yanlış olduğunu fark etmez. Her belgeye bir sahip ve bir tazeleme aralığı verin, veremiyorsanız o belgeyi hiç üretmeyin.