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

Yazılımcının Kullanıcı Deneyimine Yapabileceği Somut Müdahaleler

Geliştirici Ekipler İçin Uygulanabilir UX İyileştirmeleri

Bir yazılımcının kullanıcı deneyimine katkısı çoğunlukla tasarım dosyasında değil, hangi işi yapıp hangisini yapmadığına karar verdiği yerde başlar. Kod çalışıyor olabilir, ekran yine de kimsenin işini bitiremediği bir yer olabilir. Aşağıdaki müdahaleler tasarımcı kadrosu olmayan ekiplerde de uygulanabilir ve hepsinin etkisi ölçülebilir.

Önceliği kullanım verisi belirlesin

Hangi özelliğin iyileştirileceği sorusu genelde ekip içi tartışmayla cevaplanır, oysa uygulamanın kendi logları daha net konuşur. Hangi ekran günde kaç kez açılıyor, hangi akış yarıda bırakılıyor, hangi buton hiç tıklanmıyor. Bu üç soruya cevap veren basit bir olay kaydı, haftalarca süren öncelik toplantısından fazlasını söyler.

Trafiği yüksek bir ekranda yapılan küçük bir düzeltme, kimsenin girmediği bir modülün baştan yazılmasından çok daha fazla insana dokunur. Kaynak sınırlıysa hesap bu kadar basit.

Az kullanılan özelliği silmeden önce

Zamanla biriken, kimsenin bakmadığı modüller arayüzü ağırlaştırır ve temizlik doğru bir refleks. Ama kullanım verisinin bir kör noktası var: analitik yalnızca insanların yapabildiği şeyi ölçer. Bir özellik bozuksa, yanlış yerde duruyorsa veya adı anlaşılmıyorsa kullanım oranı düşük görünür, tam da bu yüzden silme listesine girer. Silinen şey ilgisizlik değil, erişilemeyen bir ihtiyaç olabilir.

Kullanım oranı düşük diye bir özelliği doğrudan kaldırmam. Önce o akışa kaç kişinin başlayıp kaçının bitirdiğine bakarım. Başlayan çok, bitiren azsa ortada talep vardır ve engel arayüzdedir. Başlayan da yoksa silin, arayüz rahatlar.

Hız ayrı bir özellik değil, geri kalanının ön koşulu

Kullanıcı yavaşlığı "yavaş" diye tarif etmez, "bozuk" diye tarif eder. Üç saniyede açılan bir liste ekranında kullanıcı sayfanın kendisini değil, kendi tıklamasının işe yarayıp yaramadığını sorgular, sonra bir kez daha tıklar.

Arayüz tarafındaki optimizasyonlar en görünür olanlar, ama zamanın büyük kısmı çoğu projede veritabanına gidip gelmekte harcanıyor. Listeleme ekranında satır başına ayrı sorgu atan bir döngü, tek başına sayfayı yarım saniyeden üç saniyeye taşır. Görselleri sıkıştırmaya girişmeden önce sayfanın attığı sorgu sayısına bakın; sonuç genelde oradan çıkar. Önbellek ve CDN bundan sonra gelir, çünkü ikisi de zaten hızlı olan bir şeyi yaymaya yarar.

Varsayılanlar kitleye göre ayarlanır

Her kullanıcının aynı üç ayarı elle değiştirmesi gerekiyorsa, o ayarların varsayılanı yanlış demektir. Kullanıcılarınızın çoğunluğu tek ülkedeyse ülke alanı boş açılmasın, tarih biçimi o bölgenin biçimi olsun, en sık seçilen ödeme yöntemi listenin başında dursun. Bunları esnek bırakmak yeterli: değiştirmek isteyen değiştirir, çoğunluk hiç dokunmaz.

Aynı mantık form alanları için de geçerli. Zorunlu olmayan alanı zorunlu yapmak, ortalama doldurma süresini artırdığı gibi hatalı veri oranını da artırır, çünkü insanlar zorunlu alanı geçmek için bir şeyler uydurur.

Arayüz kararı ilk commit'ten önce ucuzdur

Kağıt üzerindeki bir taslakta ekran akışını değiştirmek on dakika sürer. Aynı değişikliği yayındaki üründe yapmak veri şemasına, API sözleşmesine, testlere ve mevcut kullanıcıların alışkanlığına aynı anda dokunmayı gerektirir. Aradaki fark iki kat değil, iki basamak.

Yarım saatlik bir tıklama testi ciddi sorunların çoğunu yüzeye çıkarır. Gerçek kullanıcı bulunamıyorsa ürünü daha önce hiç görmemiş bir meslektaş da iş görür. Aranan şey istatistik değil, insanın ilk takıldığı an ve o an neredeyse her zaman ekibin sorunsuz saydığı yerde geliyor.

Kaynaklar