Kullanıcı Akışı Tasarımı ve Prototiplemenin Pratiği
Kullanıcı akışı, bir kişinin üründe A noktasından B noktasına giderken attığı adımların sırasıdır. Prototip ise o sırayı, kod yazılmadan önce denemenin yoludur. İkisi birlikte çalıştığında bir tasarım kararını yanlışlamak birkaç saat sürer; ayrı çalıştığında aynı kararı üç ay sonra canlıda öğrenirsin.
Akış, sayfa haritası değildir
Sayfa haritası ürünün neyi nerede tuttuğunu gösterir. Akış tek bir amacın peşinden gider: parolasını unutan biri hesabına nasıl döner, stokta kalmayan ürünü seçen biri ne görür. Aynı ekran iki farklı akışta bambaşka rol üstlenir, bu yüzden akışı sayfa listesinden türetmek çoğu zaman ters yönde ilerlemek olur. Önce amacı bir cümleyle yaz, sonra o cümlenin geçtiği ekranları sırala.
Amaç tek satırda yazılamıyorsa akış da kurulamaz. "Kullanıcı ürünleri keşfeder" bir amaç değil, temennidir. "Kullanıcı, beden seçimi olan bir ürünü sepete ekler" ölçülebilir bir amaçtır ve nerede tıkanacağını baştan söyler.
Karar noktaları çoğaldıkça yol sayısı patlar
Akıştaki her ikili karar noktası olası yol sayısını ikiye katlar. Beş karar noktası otuz iki yol eder. Hepsini prototipe çevirmeye kalkan ekip ilk haftasını ana yolda değil kenar durumlarda harcar, sonra takvim biter ve ana yol hiç test edilmemiş olur.
Yapılacak iş, yolları eşit görmeyi bırakmak. Bir ana yol seç, bir de gerçekten sık karşılaşılan hata dalı. Hangi dalın sık olduğunu tahminle belirleme: ürün yayındaysa bu bilgi zaten kayıtların içinde duruyor, form hatalarının hangi alanda toplandığına bakmak yarım saatlik iş. Kalan yollar diyagramda dursun, prototipe girmesin.
Az adım her zaman iyi adım değil
Akış tasarımına dair en sık verilen tavsiye, adım sayısını azaltmaktır. Bu tavsiye tek başına yanıltıcı, çünkü adım sayısı kullanıcının harcadığı eforu değil, ekranların bölünme biçimini ölçer. On iki alanı tek sayfaya yığarsan akış üç adımdan bire iner, form ağırlaşır. Aynı on iki alanı dörderli üç ekrana bölersen adım sayısı artar, ekran başına verilen karar sayısı düşer.
Bakman gereken şey adım değil, adım başına düşen karar. Kullanıcı bir ekranda tek bir şeye karar veriyorsa o ekran ucuzdur. Üç şeye birden karar veriyorsa, akışı üç adımdan bire indirmiş olman kimseyi kurtarmaz.
Prototipin sadakati soruya göre seçilir
Sıra doğru mu, ekran eksik mi, kullanıcı nerede duraklıyor. Bu sorular için kutu ve ok yeter. Sıralamayı tartışacağın toplantıya yüksek sadakatli ekran götürme; insanlar renk ve yazı tipi konuşmaya başlar, akışı konuşmaz. Cilalı prototipi buton hiyerarşisi, boşluk hissi, mikro etkileşim gibi sorulara sakla.
- Senaryoyu yaz: kullanıcı nereden geliyor, ne yapmaya çalışıyor, neyi bilmiyor.
- Ekranları kabaca çiz, aralarındaki geçişleri tıklanabilir hale getir.
- Birkaç kişiye yaptır, konuşturmaya çalışma, nerede durakladıklarına bak.
Üçüncü adımda çıkan bulguların çoğu ekranların içinde değil, ekranlar arasındaki boşlukta olur: kullanıcı bir sonraki adımda ne olacağını bilmediği için tıklamaz.
Diyagramda çizilen geçişin kodda karşılığı var mı
Çizmesi bedava olan bazı oklar üründe pahalıdır. "Kullanıcı kaldığı yerden devam eder" yazan bir geçiş, form durumunun sunucuda saklanmasını gerektirir. Durum yalnızca tarayıcı belleğindeyse o ok gerçekte yoktur, sekme kapandığında kullanıcı en başa döner. Geri butonu da diyagramda zararsız bir çizgidir, oysa ödeme adımında geri gitmek çoğu sistemde sipariş kaydını ikiye böler.
Ucuz çözümü, akışı bir geliştiriciyle birlikte okumak. Her okun yanına o geçişi mümkün kılan şeyi yaz: oturum, saklanan taslak, yeniden denenebilir istek. İkinci faydası da var: akıştaki adımlara verdiğin isimleri ölçüm olaylarının isimleriyle aynı tutarsan, aynı diyagram sonradan huni raporunun iskeleti olur ve prototipte doğru sandığın sırayı gerçek veriyle karşılaştırabilirsin.