Omnichannel Tutarlılık: Aynı Görünmek Değil, Aynı Model
Kanallar arası tutarlılık genelde “her yerde aynı görünsün” diye anlaşılıyor ve bu okuma yanlış tarafı sabitliyor. Aynı kalması gereken şey ekranın görüntüsü değil, arkadaki model: kullanıcının ne yapabildiği, bunu hangi isimle yapabildiği ve verinin hangi anda güncellendiği. Görsel dil bunun üstüne gelir, platformun kendi kurallarına da yer bırakarak.
Tutarlılık tek bir şey değil, üç katman
Bir kullanıcının telefonda başlayıp masaüstünde bitirdiği bir işi düşün. O yolculukta üç ayrı şeyin tutarlı olması gerekir ve üçü farklı ekiplerin işidir.
Birincisi işlevsel kapsam: mobilde yapılabilen bir şeyin webde de yapılabilmesi. İkincisi durum ve veri: sepete eklenen ürünün, iptal edilen siparişin, değişen adresin diğer kanalda gecikmeden görünmesi. Üçüncüsü dil ve görsel kimlik: aynı işlemin her iki yerde aynı adla anılması, aynı ikonla temsil edilmesi.
Bu ayrımı yapmak işe yarıyor, çünkü üç katman aynı anda bozulmuyor. Çoğu üründe işlev ve görsel kimlik hizalı durur, sessizce ayrışan katman durum senkronizasyonudur. Kullanıcı bunu “uygulama yanlış gösteriyor” diye yaşar, güven de tam orada gider.
Aynı görünmek ile tutarlı olmak
Tutarlılığın iki yönü var. İçeride tutarlılık, ürünün kendi içinde aynı şeyi hep aynı biçimde yapmasıdır. Dışarıda tutarlılık ise kullanıcının başka yerlerden edindiği alışkanlığa uymaktır; insanlar zamanlarının çok küçük bir kısmını senin ürününde geçirir, beklentileri geri kalan her yerden gelir.
Kanal sınırında bu ikisi çarpışır. iOS'ta geri hareketi kenardan kaydırmadır, Android'in kendi sistem geri davranışı vardır, webde tarayıcının geri düğmesi çalışır. Üçüne de aynı görünen özel bir geri düğmesi koymak ürün içinde tutarlılık üretir, kullanıcının alışkanlığını bozar. Tasarım sistemini kanal başına çatallamam, ama bileşenin platform davranışını taklit etmesini de engellemem: renk, tipografi ve terminoloji ortak kalır, etkileşim yerelleşir.
Dokunma hedefi de aynı yerden okunur. Masaüstünde 32 piksellik bir düğmeye fareyle rahat basılır, telefonda aynı ölçü ıskalanır. Görsel eşitlik adına ikisini aynı yapmak, tutarlılığı kullanılabilirliğin önüne koymaktır.
Senkronizasyonun faturası tasarım dosyasında görünmez
“Her kanalda aynı veri” cümlesi bir sunumda bedavadır, uygulamada değil. Kanalları birbirine doğrudan bağlarsan kurulacak ve bakımı yapılacak bağlantı sayısı n(n-1)/2 ile büyür: dört kanalda altı, beş kanalda on entegrasyon. Hepsi tek bir kaynağa bağlanırsa sayı n'e iner, beş kanalda beş. Aradaki fark kanal sayısı arttıkça açılır, o yüzden kanal eklemenin maliyeti hangi modeli seçtiğine bağlıdır.
Yani kanallar arası tutarlılık kararı aslında bir mimari kararı. Sepet, oturum, sipariş durumu gibi paylaşılan şeylerin tek bir yerde tutulup tutulmadığını sormadan verilen tutarlılık sözü, sonradan her kanal çiftini elde uzlaştırmak demek.
Ardından çakışma sorusu gelir: aynı sepet iki cihazda aynı anda değiştiğinde hangisi kazanır? Bunun bir cevabı olmak zorunda ve cevabı tasarımın vermesi gerekir, çünkü sonucu görecek olan taraf kullanıcı. Son yazan kazanır kuralı ucuzdur, alışveriş listesinde kabul edilebilir. Ödeme adımında değildir.
Nerede bozulduğunu nasıl görürsün
Kanal içi testler bu hataları bulmaz, çünkü her kanal kendi içinde doğru çalışıyordur. Görevin kanal sınırını geçmesi gerekir: kullanıcı telefonda başlasın, yarıda bıraksın, masaüstünde devam etsin. Burada ölçtüğün şey görevin tamamlanması değil, devam edilen noktada ürünün doğru durumu gösterip göstermediği.
Ucuz bir kontrol daha var. Aynı işlemin kanallardaki adlarını bir tabloya yan yana yaz. “Üyelik”, “hesap” ve “profil” aynı şeyi anlatıyorsa terminoloji çoktan ayrışmış demektir. Bu tabloyu çıkarmak birkaç saat sürer ve genelde kimsenin haberi olmadığı bir uyumsuzluk listesi verir.
Hedefi de buna göre yaz. “Her kanal aynı olsun” değil, “kullanıcı kanal değiştirdiğinde hiçbir şeyi yeniden öğrenmek ve yeniden girmek zorunda kalmasın”. İki cümle kulağa yakın gelir, tasarım kararlarını çok farklı yerlere götürür.