UX ve Servis Tasarımı: Sınır Nerede, Ne Zaman Hangisi

UX ile servis tasarımı arasındaki fark çoğu yazıda "biri ön yüz, diğeri arka plan" diye özetlenir. Bu özet pratikte pek işe yaramaz, çünkü ön yüzde gördüğünüz sorunların büyük kısmı arka planda başlar. Ayrımı yararlı kılan tek soru şu: elinizdeki sorunu bir ekran değişikliğiyle mi, yoksa birinin iş tanımını değiştirerek mi çözeceksiniz?

Yaygın tanım kendi içinde çelişiyor

Standart anlatım UX'i "kullanıcının markayla temas ettiği her nokta" diye tanımlar; çağrı merkezi, mağaza, fatura, hepsi dahil. Sonra aynı anlatım servis tasarımını "arka planı kuran yaklaşım" diye ayırır. İkisi bir arada tutarsız: temas noktalarının tamamı zaten UX'in kapsamına alındıysa geriye servis tasarımına ait ayrı bir alan kalmıyor, sadece isim değişiyor.

Daha kullanışlı bir çizgi var. UX, kullanıcının o an algıladığı şeydir. Servis tasarımı, o algının her seferinde tekrarlanmasını sağlayan kaynak taahhüdüdür: kaç kişi, hangi yetkiyle, hangi sistemde, hangi sürede. Bir deneyimi bir kez yaşatmak tasarım sorunu, bin kez aynı kalitede yaşatmak kapasite sorunudur.

Canlı destek örneği ayrımı görünür kılıyor

Kullanıcı sitede takılıyor, sohbet penceresini arıyor. Pencerenin nerede durduğu, açılınca ne yazdığı, yazarken karşı tarafın yazdığını görüp görmediği arayüz meselesi. Bunları bir sprintte düzeltebilirsiniz.

Mesajı yazdıktan sonrası artık başka bir şey. Talep hangi kuyruğa düşüyor, o kuyrukta o saatte kaç kişi var, ilk yanıtı veren kişi konuyu çözme yetkisine sahip mi, sahip değilse aktarma sırasında kullanıcının anlattıkları taşınıyor mu? Sohbet kutusunun tasarımı bu soruların hiçbirini etkilemez. Kullanıcı için ise ikisi tek bir deneyim: "yardım istedim, çözüldü" ya da "çözülmedi".

Ayrımın pratik karşılığı burada ortaya çıkıyor. Yanıt süresi mesai bitiminde on kat artıyorsa yeni bir ekran taslağı hazırlamanın anlamı yok; vardiya planı değişmeden o sayı düşmez.

Blueprint'in değeri kutularda değil, geçişlerde

Servis blueprint'i genelde "yolculuğun her adımını, arkasındaki süreçlerle birlikte haritalayın" diye anlatılır. Uçtan uca çizilen bu haritaların çoğu bir kez hazırlanır, duvara asılır ve altı ay içinde gerçeği yansıtmayı bırakır. Sorun yöntemde değil, kapsamda.

Bir blueprint'te asıl bilgi, kullanıcı eylemi ile perde arkası arasındaki her geçiş noktasında saklıdır: talebin bir ekipten diğerine, bir sistemden ötekine atladığı yerler. Aksaklıklar kutuların içinde değil, bu kutuların arasındaki oklarda birikir, çünkü hiçbir ekip kendi kutusunun dışını sahiplenmez. Yolculuğun tamamını çizmek yerine yalnızca bu geçişleri listeleyip her biri için tek bir soruyu cevaplamak çoğu durumda yeterli oluyor: burada bilgi kaybolursa kim fark eder?

Otomasyon ile sürekli geri bildirim aynı anda istenemez

Aynı listede iki tavsiyeyi yan yana görürsünüz: tekrar eden arka plan işlerini otomatikleştirin, bir yandan da geri bildirime göre süreci sürekli güncelleyin. Bunlar birbirini yavaşlatır. Bir kural insanın kararındayken bir toplantıda değişir; aynı kural koda gömüldüğünde her değişiklik bir geliştirme, bir test ve bir sürüm demektir. Süreci ne kadar otomatikleştirirseniz, geri bildirime cevap verme hızınız o kadar düşer.

Otomasyonu akışın oturmuş kısmına koy, hâlâ tartıştığınız kısmına dokunma. Yönlendirme kuralları üç ayda bir değişiyorsa onları koda değil, destek ekibinin düzenleyebileceği bir tabloya yaz; aynı davranışı elde edersin, değiştirmek için sürüm beklemezsin.

Hangi sorun hangisine ait

Kullanışlı bir ayraç şu: sorun her kullanıcıda aynı adımda, aynı biçimde tekrarlıyorsa sürece aittir. Kullanıcıdan kullanıcıya değişiyor, kimisi takılıp kimisi rahatça geçiyorsa arayüze aittir.

Formun ikinci adımında bırakma oranı yüksek, ama bırakanların profili karışıksa orada anlaşılmayan bir alan vardır. Buna karşılık siparişlerin tamamı aynı yerde, aynı gecikmeyle bekliyorsa arayüzde düzeltecek bir şey yok; bekleyen şey bir onay, o onayı verecek kişi de muhtemelen bunun kendi işi olduğunu bilmiyor.