Personayı Canlı Tutmak: Güncelleme Eşiği ve Biçim Seçimi

Persona yazmak kolay, canlı tutmak zor. Çoğu ekipte dosya ilk çeyrekte hazırlanır, sonra kimse açmaz; altı ay sonra içindeki kullanıcı, ürünü gerçekten kullanan kişiye benzemez. Sorun personanın eskimesi değil, eskidiğini kimsenin fark etmemesi.

Bayatlamayı nasıl fark edersiniz

Bir personanın hâlâ iş gördüğünü ölçmenin en kısa yolu şu soru: son üç ayda hangi tasarım kararını değiştirdi? Bir alanı zorunludan isteğe çevirdi mi, bir özelliği kuyruğun sonuna attı mı? Cevap gelmiyorsa dosya artık referans değil, dekordur.

Bu soru takvimden daha iyi bir ölçüdür, çünkü persona yaşından değil kullanımdan düşer. Altı aydır hiçbir karara dokunmamış bir persona, dün güncellenmiş olsa bile işlevsizdir.

Güncelleme eşiği

Her yeni veri parçası için dosyayı baştan yazmak gereksiz. Revizyonu hak eden değişiklikler oldukça belirli:

• Yeni bir kullanıcı segmentine ya da pazara giriliyor ve eldeki profillerin hiçbiri o kişiyi kapsamıyor.
• Kullanım verisi personadaki bir varsayımla çelişiyor; masaüstü ağırlıklı tanımladığınız kitlenin oturumlarının yarısı mobilden geliyor diyelim.
• Yeni bir araştırma turu bitti ve notlar mevcut profillerden birini düzeltiyor.

Takvime bağlı gözden geçirme (çeyrekte bir saat) bunların yerine geçmez ama üstüne iyi oturur: gelen girdi varsa revizyon tetiklenir, yoksa toplantı beş dakikada kapanır. Takvimi tek mekanizma yaparsanız ritüele dönüşür, kimse dosyayı açmadan "güncel" der.

Biçim, güncellemenin maliyetini belirler

Persona bir PDF'e ya da katmanlı bir tasarım dosyasına gömüldüğü anda güncelleme tek bir kişiye bağlanır, o kişi de genelde meşguldür. Dosyayı açıp iki satır değiştirmenin maliyeti yükseldikçe değişiklik ertelenir, ertelendikçe içerik gerçeğin gerisinde kalır. Google Dokümanlar ya da ekibin wiki sayfası bu yüzden şık bir sunumdan uzun ömürlü çıkar.

Persona metnini genelde ürün deposunda düz bir metin dosyasında tutarım. Güncelleme bir pull request'e dönüşüyor, gerekçesi commit mesajında kalıyor, hangi kararın hangi persona sürümünde alındığı sonradan aranabiliyor.

Bu son nokta çoğu persona rehberinin atladığı yer. "Güncelleme yetkisini yayın" tavsiyesi doğru, ama tek başına verildiğinde iz bırakmayan bir dosya üretir. Üç ay önce kitleyi acelesi olan mobil kullanıcı diye tanımladığınız için onay adımını kaldırdıysanız ve o satır bugün dosyada yoksa, kararın gerekçesi de ortadan kalkmış olur. Akışa sonradan bakan biri yanlış soruyu sorar. Sürüm geçmişi tutmak, yetkiyi dağıtmanın şartı; süsü değil.

Görsel sunum ayrı bir iş

Üst yönetime ya da yeni katılan bir ekibe persona tanıtırken iyi tasarlanmış bir çıktı işe yarar, kimse ham notlardan etkilenmez. Ama aynı dosyanın hem sunum hem çalışma kopyası olmasını beklemeyin. Sunumu çalışma dosyasından türetin, tersini değil.