Mobil UX'te Beş Temel Kriter ve Birbiriyle Çakıştıkları Yer
Mobil UX yazılarının çoğu beş maddeyi alt alta sıralar ve hepsini aynı anda uygulamanızı ister. Sahada işler öyle yürümüyor: butonu büyütmek listeyi kısaltmayı, iskelet ekran koymak biraz daha JavaScript yüklemeyi gerektiriyor. Aşağıdaki beş kriteri, birbirlerini nerede kestikleriyle birlikte yazdım.
Hız, diğer dördünün üstüne kurulduğu zemin
Yavaş açılan bir ekranda tipografi tartışmasının kıymeti yok. Mobilde bağlantı kalitesi masaüstündeki gibi öngörülebilir değil, cihaz da tek çekirdekli bir tarayıcı ana iş parçacığıyla uğraşıyor. Görselleri hedef ekran boyutuna göre üretmek, srcset ile doğru varyantı sunmak ve yazı tiplerini sayfayı bloklamayacak şekilde yüklemek, çoğu sitede toplam süreyi diğer bütün mikro iyileştirmelerin toplamından fazla düşürüyor.
Eski rehberlerden devralınan bir tavsiye burada artık ters çalışıyor: "arka planı tekrar eden küçük parçalara böl." Bu, her isteğin pahalı olduğu HTTP/1.1 dönemine ait bir refleks. HTTP/2 ve sonrasında istek başına maliyet düştü, buna karşılık tekrar eden desenin döşenmesi cihazın işlemcisine iş çıkarıyor. Tek bir WebP dosyası çoğu durumda hem daha küçük hem de daha ucuz.
Dokunma alanı bir tercih değil, bütçe
Apple'ın insan arayüzü kılavuzu 44pt, Google'ın Material tasarımı 48dp asgari dokunma alanı öneriyor. Bunu bir stil kararı gibi okumak yanlış. Aritmetiği yapın: 48dp yükseklikte dört düğmeyi aralarında 8dp boşlukla alt alta koyduğunuzda 4 x 48 + 3 x 8 = 216dp yer kaplar. Tipik bir telefonda tarayıcı çubukları düştükten sonra elinizde kalan yaklaşık 640dp'lik dikey alanın üçte biri gitti.
Sonuç şu: "butonları büyütün" ile "her şey ilk ekranda olsun" aynı anda tutmaz. Birini seçmek zorundasınız ve doğru seçim neredeyse her zaman öğe sayısını azaltmaktır. Menüyü altı maddeden üçe indirmek, her maddeyi 40dp'ye sıkıştırmaktan iyidir; çünkü ikincisinde kullanıcı yanlış maddeye basar, geri döner ve aynı ekranı iki kez yükler.
Niyeti tahmin etmeyin, ölçün
Mobilde gelen kullanıcı genellikle dar bir amaçla gelir: bir fiyata bakmak, adres bulmak, siparişin nerede olduğunu öğrenmek. Bu üç şey masaüstü ana sayfanızın vitrin alanında değil, çoğu zaman üç tık aşağıdadır.
Analitikte mobil oturumların en çok gittiği ilk beş sayfayı çıkarın ve ana sayfada bunlara doğrudan bir yol olup olmadığına bakın. Bu liste tahminlerinizle uyuşmuyorsa doğru olan liste, tahmin değil. Arama kutusu da burada devreye giriyor: navigasyonu düzeltemiyorsanız aramayı görünür yapmak, en azından kullanıcının kendi yolunu bulmasına izin verir.
Algı yönetimi bir onarım aracıdır, çözüm değil
İskelet ekranlar ve ilerleme göstergeleri işe yarar, ama ne zaman işe yaradıklarını belirtmeden önermek yanıltıcı oluyor. Bir saniyenin altındaki beklemelerde gösterge koymak deneyimi iyileştirmez, hatta bir titreşim (görünüp hemen kaybolan bir yükleniyor animasyonu) yaratıp sayfayı daha kırık gösterir. Göstergenin değeri, bekleme birkaç saniyeye çıktığında ortaya çıkar.
Bir de şu tuhaflık var: iskelet ekran bedava değil. Onu çizen kod da indirilip çalıştırılıyor. Sunucudan gelen HTML'i iki yüz milisaniyede boyayabilecek bir sayfaya, sırf modern görünsün diye istemci tarafında iskelet katmanı eklemek, algıyı düzelteyim derken gerçek süreyi uzatır. Önce ölçün, gösterge sonra.
Rakibe bakarken neyi ölçtüğünüzü bilin
Rakip uygulamayı açıp "daha şık görünüyor" demek analiz değil. Karşılaştırmayı görev üzerinden kurun: ürünü sepete eklemek kaç dokunuş sürüyor, kayıt formu kaç alan istiyor, kargo takibi giriş yapmadan mümkün mü. Bu sorular sayıyla cevaplanır ve sayı, tasarım zevkinden tartışmaya daha açıktır.
Aynı ölçümü kendi ürününüzde de yapın, ilk kez o zaman kıyas anlamlı olur. Sekiz dokunuşluk bir ödeme akışının beşe inmesi, ana sayfadaki görsel yenilemesinden daha çok kazandırır, üstelik daha ucuza mal olur.
Kaynak