Kullanıcı Odaklı Tasarımı Müşteriye Anlatmak
Kullanıcı odaklı tasarım, ürünün nasıl görüneceğine karar vermeden önce onu kimin, hangi koşulda kullanacağını öğrenmeyi şart koşar. Yöntem olarak öğrenmesi kolay, kaynağı bol. Zor kısım, teklifte satır olarak duran bu süreyi müşteriye anlatmak: karşılığında gösterebileceğiniz bir ekran yok, sadece sonradan yapılmayacak işler var.
Yöntem aslında ne yapıyor
Kullanıcı odaklı tasarımın (user-centered design) tek bir iddiası var: ürünü kullanacak kişi, tasarım kararlarının kaynağı olsun, kararlar alındıktan sonraki onay mercii değil. Fark pratikte şurada görünür. Klasik akışta ekip tasarımı bitirir, sonra kullanıcıya gösterir ve beğenip beğenmediğini sorar. Diğerinde soru en başta sorulur, cevabı da ekranın nasıl kurulacağını belirler.
Süreç dört adıma iner: kimin kullanacağını tanımlamak, o kişiyle konuşup yaptığı gerçek işi görmek, ucuz bir taslak çıkarıp kullanırken izlemek, çıkanı değiştirmek. Adımların isimleri kaynaktan kaynağa değişiyor, sırası değişmiyor.
Müşteriyi ikna eden argümanlar
Ortalıkta dolaşan altı maddelik fayda listelerinin çoğu doğru ama satmıyor, çünkü müşterinin sormadığı soruya cevap veriyorlar. Toplantıda iş gören iki tane var.
Birincisi yeniden yapım maliyeti. Yanlış kurgulanmış bir akış canlıya çıktıktan sonra düzeltilir, düzeltmek de geliştirme, test ve yeniden yayın demektir. Müşteri bunu tanır çünkü daha önce yaşamıştır. Karşınızdaki kişiden bir kere şu ekranı üç kere yaptık cümlesini duyduysanız argümanınız hazır.
İkincisi destek yükü. Anlaşılmayan arayüz telefonla, e-postayla, WhatsApp mesajıyla geri döner. Destek maliyeti müşterinin bütçesinde zaten bir yerde duruyor, tasarım bütçesinde durmuyor. İkisini aynı tabloda yan yana koymak çoğu zaman uzun anlatımlardan hızlı sonuç veriyor.
İşe yaramayan argüman ise kullanıcı memnuniyeti artar. Ölçmediğiniz bir şeyi vaat etmiş olursunuz, karşınızdaki de bunu bilir.
Erken test hangi kararlarda para kazandırır
Hatayı erken yakalamanın ucuza geldiği doğru, ama genelleştirilince yanlışa dönüyor. Her kararın sonradan düzeltme maliyeti aynı değil.
Buton rengi, metin, boşluk: bunlar canlıda da beş dakikada değişir, prototip toplantısında tartışılması zaman kaybıdır. Pahalı olanlar veriye ve akışın iskeletine gömülü kararlar. Tek adımlık bir formu üç adıma bölmeye karar verdiğinizde kaydetme mantığı, doğrulama, yarım kalan kaydın saklanması ve geri dönüş davranışı birlikte değişir; yayından sonra bu bir gün değil bir hafta. Kullanıcının neye sahip olduğu (hesap mı, takım mı, proje mi) sorusu daha da beter, çünkü cevabı şemaya yazılır ve sonradan değiştirmek veri taşımayı gerektirir.
Ölçüt basit: karar veritabanına ya da akışın iskeletine dokunuyorsa prototipte test et. Görselde kalıyorsa canlıda düzeltirsin, teste harcadığın süre geri gelmez.
Teklif aşamasında işe yarayanlar
- Kullanıcı görüşmesini müşteriyle birlikte izleyin. Kendi ürününün kullanılamadığını canlı gören müşteri, o günden sonra bütçeyi savunan taraf olur.
- Araştırmayı ayrı kalem olarak yazmayın. Keşif adıyla ayrı satırda duran her şey, kesilecek ilk satırdır.
- Bir önceki projeden önce ve sonra ekranlarını gösterin; elinizde ölçüm varsa rakamla, yoksa rakamsız.
Yapılmayacak şey, sektörden ezbere yüzde vermek. Kaynağını gösteremediğiniz her oran aynı toplantıda size soru olarak geri döner ve o andan sonra anlattığınız her şey tartışmalı hale gelir.
Kaynaklar