UX Proje Brief'i: Kapsamı Kapatan Belge Nasıl Yazılır
Bir UX brief'in işi ilham vermek değil, tartışmayı kapatmak. Proje ortasında “biz bunu konuşmuştuk” denen şeyi yazılı hale getirir: kim için, hangi sınırlar içinde, ne teslim edilecek. Çoğu brief bunu beceremiyor, çünkü hedef bölümünde sade bir ilk sürümden söz ederken kapsam bölümünde on maddelik istek listesi taşıyor.
Brief hangi soruları kapatır
Dört başlık yeter. Projenin amacı tek cümlede, kapsamın dışarıda bıraktıkları, kullanıcının kim olduğu ve tasarımdan ne teslim edileceği. Gerisi doküman şişkinliği.
Örnek olarak bir hayvan barınağı projesini alalım. Amaç cümlesi şöyle kurulabilir: barınaktaki hayvanı sahiplenmek isteyen ziyaretçiyle barınağı günlük olarak yöneten çalışanı aynı kayıt sistemi üstünde buluşturmak. İki kullanıcı, iki arayüz, tek veritabanı. Bu cümleyi yazdığınız anda projenin yarısı hakkında karar vermiş olursunuz.
MVP yazan brief, MVP olmayan liste
Brieflerin en sık düştüğü tutarsızlık burada. Kapsam başlığının altında “minimum uygulanabilir ürün” yazar, hemen ardından gelen maddelerde yapay zekâ destekli eşleştirme, kişiselleştirilmiş öneriler, kullanıcı topluluğu ve eğitici içerik akışı sıralanır. Bunların hiçbiri minimum değil. Yapay zekâ destekli eşleştirme için önce eşleştirilecek veri, o veriyi üretecek kullanıcı davranışı ve davranışı toplayacak çalışan bir ürün gerekir; yani sıralamada en sona düşer, başa değil.
Pratik ölçüt şu: bir maddeyi çıkardığınızda ürün hâlâ amaç cümlesini yerine getiriyorsa, o madde ilk sürümde değildir. Barınak örneğinde ilan listesi, ilan detayı, başvuru formu ve bağış akışı kalır. Öneri motoru çıkar, topluluk çıkar. Çıkanları silmeyin, “ikinci sürüm” başlığının altına taşıyın. Yazılmayan istek kapsamdan çıkmış sayılmaz, sadece sözlü olarak dolaşmaya devam eder ve üç ay sonra sürpriz diye geri gelir.
Ziyaretçi tarafı, çalışan tarafı
Aynı projede iki ayrı deneyim var ve brief genelde birine haksızlık ediyor. Ziyaretçi tarafı sayfalarca anlatılır, yönetim tarafı en sona sıkışan tek paragrafa kalır. Oysa ziyaretçi siteyi birkaç dakika kullanır, çalışan mesaisinin büyük bölümünü o ekranda geçirir.
Ziyaretçi tarafında aranan şey açıklık: hangi hayvan sahiplenmeye uygun, başvuru nasıl yapılıyor, bağış nereye gidiyor. Yönetim tarafında aranan şey hız: ilanı üç tıkla yayına alma, başvuruyu durum etiketiyle izleme, bağış raporunu tarih aralığıyla dışa aktarma. İlkinde fazladan bir tıklama tolere edilir. İkincisinde günde otuz kez tekrarlanan fazladan adım, doğrudan maliyettir.
Persona kartı kısa olsun
Persona, bir tasarım kararını değiştiriyorsa işe yarar. “45 yaşında, kahve seviyor, hafta sonları yürüyüşe çıkıyor” bilgisi hiçbir ekranı değiştirmez. “Barınağa gitmeden önce hayvanın sağlık geçmişini görmek istiyor, göremezse aramaya devam ediyor” bilgisi ilan detay sayfasının içeriğini belirler. İkinci tür cümleyi kurabiliyorsanız persona kartının bir paragrafı geçmesine gerek kalmaz.
Yolculuk haritası için de aynısı geçerli. Adımları değil, adımlar arasındaki kopuşları yazın. Başvuru formunu dolduran kişi ne zaman geri dönüş alacağını bilmiyorsa, haritada işaretlenecek yer tam orasıdır.
Prototipe gerçek içerik koyun
Orta sadakat doğru seviye. Renk ve tipografi kararlarını erken vermek, henüz oturmamış bir akışı görsel olarak savunmaya başlamak demek. Ama sadakati düşürmek, içeriği uydurmak anlamına gelmiyor.
Lorem ipsum'la doldurulmuş ilan kartı her zaman düzgün görünür, çünkü metin kutuya göre kesilmiştir. Gerçek veri öyle davranmaz: bir ilan başlığı “Tekir” olur, diğeri “Sokakta bulundu, tedavisi sürüyor, sakin bir eve ihtiyacı var” olur. Kart yüksekliği kayar, ızgara bozulur, buton alta düşer. Test edeceğiniz ekrana veritabanındaki en uzun ve en kısa kaydı koymak, tek başına birkaç saatlik yeniden tasarımı önler. Bu sorunu prototipte görmezseniz üretimde görürsünüz, üstelik veri girmiş gerçek kullanıcılarla birlikte.
Brief'in bir tarihi olsun
Brief donmuş belge değil. İlk kullanıcı testinden sonra en az bir maddesi yanlış çıkar, çünkü brief varsayımla yazılır ve testin işi varsayımı kırmaktır. Belgenin başına tarih ve sürüm numarası koyun; değişen maddeyi silmek yerine üstünü çizip nedenini yazın. Altı ay sonra “bu özelliği neden yapmadık” sorusu geldiğinde cevabı aramakla vakit kaybetmezsiniz.