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

UX Olgunluğunu Artıran İletişim: Kanal Seçimi ve Gerçek Maliyeti

Senkron ve Asenkron UX İletişimi Nasıl Dengelenir

Bir kurumda UX olgunluğu, tasarımcıların yeteneğinden çok bulguların içeride nasıl dolaştığına bağlı. Aynı kullanıcı testi iki şirkette yapılır; birinde sunum dosyası olarak kalır, diğerinde iki hafta içinde üründe karşılığını bulur. Aradaki fark yöntem değil, bulgunun hangi kanaldan kime ulaştığı ve o kanalın kaça mal olduğu.

Olgunluk tavsiyesinin içindeki döngü

Bu konudaki yazıların çoğu şunu söyler: olgunluğu artırmak için ekipler arası iletişimi güçlendirin. Peki iletişim kanalı zaten yoksa? Düşük olgunluklu bir kurumda UX ekibinin bülten çıkaracağı bir liste, atölye yapacağı bir takvim aralığı, readout sunacağı bir toplantı serisi genelde yoktur. Tavsiye, çıktısı olan şeyi girdi olarak istiyor.

Bu döngüden çıkmanın yolu yeni kanal kurmak değil, var olan kanala girmek. Ürün ekibinin sprint planlamasına, destek ekibinin haftalık şikâyet özetine, yöneticinin zaten okuduğu rapora. Sıfırdan bir UX bülteni başlatmak, ilk dört sayıdan sonra kimsenin açmadığı bir e-posta serisine dönüşmeye çok yatkın.

Ne, kime, hangi kanaldan

Paylaşılacak bilginin türü ile hedef kitle çoğu zaman doğru eşleştirilmiyor. Pazarlama ekibinin kullanıcı akış şemasına ihtiyacı yok; hangi segmentin nerede vazgeçtiğini bilmek istiyor. Geliştirici ekibin persona dokümanına ihtiyacı yok; hangi ekranda hangi davranışın beklendiğini bilmek istiyor. Aynı araştırmanın iki farklı özeti, herkese gönderilen tek bir kapsamlı rapordan daha fazla iş görür.

Kanal seçimi de mesajın niteliğine göre değişir. Tartışma gerektiren, itiraz beklenen, karar çıkacak konular gerçek zamanlı bir ortamda daha hızlı ilerler. Referans niteliğindeki her şey, yani sonradan tekrar bakılacak olan araştırma çıktısı, ölçüm tanımı, karar gerekçesi, yazılı olmalıdır. Toplantıda anlatılan bir bulgu üç hafta sonra kimsenin hatırlamadığı bir cümledir.

Senkron iletişimin faturası

“Dengeli kullanın” tavsiyesi ölçü vermiyor, oysa ölçü hesaplanabilir. Senkron bir oturumun maliyeti katılımcı sayısıyla doğrusal büyür: 8 kişilik 45 dakikalık bir readout, kuruma 6 saatlik iş gücü olarak yazılır. Aynı bulguları bir buçuk saatte yazıp dağıtsanız maliyet dörtte bire iner ve doküman ortada kalır.

Bu hesap senkron iletişimi kötülemek için değil, ne zaman değdiğini görmek için işe yarar. Altı saatlik toplantı, çıktısı bir karar olduğunda ucuzdur. Çıktısı yalnızca “ekip bilgilendirildi” olduğunda pahalıdır ve o parayla bir doküman yazılabilirdi. Araştırma bulgularını genelde önce yazılı bir readout notuyla dağıtır, toplantıyı ancak yorumlar çelişmeye başlarsa kurarım; itiraz gelmiyorsa toplantı zaten gereksizdi.

Yazılı çıktının kendi problemi

Asenkron iletişimin görünmeyen tarafı şu: dokümanın maliyeti düşük ama okunma garantisi yok. Toplantıya çağırdığınız kişi en azından odadadır. Gönderdiğiniz 12 sayfalık araştırma raporunu kimin açtığını bilmezsiniz.

Peki bunu nasıl ölçersiniz? Doküman görüntülenme sayısına bakmak yanıltıcı, açmakla okumak aynı şey değil. Daha güvenilir işaret, dokümanın sonraki tartışmalarda alıntılanıp alıntılanmadığı. Bir bulgu iki hafta içinde başka birinin cümlesinde geçmişse iletişim olmuştur; geçmemişse dosya arşive gitmiştir. İkinci durumda çözüm dokümanı uzatmak değil, kısaltmak ve girişine tek cümlelik bir talep koymaktır.

Bulgu bir bilete dönüşmediyse iletişim tamamlanmamıştır

Kullanıcı testi çıktılarının en sık kaybolduğu yer, sunumla backlog arasındaki boşluk. Herkes bulguyu duyar, kimse sahiplenmez, çünkü hiçbir yerde numarası yoktur. Ya da tersi olur: bilet açılır, ama açıklaması “kullanıcılar akışı karışık buluyor” gibi uygulanamayacak kadar geneldir ve sprint sonunda kapanmadan devreder.

İşleyen hâli, bulgunun bilete dönüşürken ölçülebilir bir ifadeye çevrilmesi. “Onay adımında kullanıcılar tereddüt ediyor” yerine “ödeme özetinde kargo ücreti ayrı satır olarak gösterilmiyor, beş kullanıcının üçü geri döndü” yazarsanız geliştirici ne yapacağını bilir. Bir tasarım iddiasının kodda karşılığı yoksa o iddia henüz iletişime dönüşmemiştir, sadece paylaşılmıştır.

Nereden başlanır

Düşük olgunlukta işe yarayan hamle, kurumu eğitmeye çalışmak değil tek bir kararı UX çıktısıyla değiştirmek. Bir ekran, bir metrik, bir öncesi ve sonrası. Kullanıcı odaklılığın değerini anlatan sunum on kişiyi ikna eder; dönüşüm oranını iki puan artıran bir düzeltme, sonraki araştırma talebinin gerekçesi olur. Kültürel dönüşüm dediğimiz şey genelde bu tür birkaç somut kazanımın birikmesiyle oluyor, farkındalık kampanyalarıyla değil.