Acente yazılımında trafik, kasko ve DASK teklifleri aynı menünün altında yan yana durur; ancak arka planda birbirinden oldukça farklı süreçlerdir. Her biri farklı bilgilere ihtiyaç duyar, farklı sorgu adımlarından geçer ve farklı sonuç ekranları üretir. Tasarımcının görevi, bu farklılıkları korurken kullanıcının üç akışı da aynı sistemin parçası olarak deneyimlemesini sağlamaktır.
Bu yazıda "ayrı akış, ortak dil" ilkesinin pratikte nasıl uygulanabileceğini ele alıyoruz.
Neden Tek Bir Genel Form Yeterli Değil?
Üç branşı tek bir formda birleştirmek ilk bakışta sade görünebilir. Ancak bu yaklaşım, kullanıcıya ilgisiz alanlar gösterir, koşullu mantığı karmaşıklaştırır ve hataları artırır. Trafik ve kaskoda araç bilgisi merkezdeyken, DASK'ta araç bilgisinin hiçbir anlamı yoktur; bina ve adres bilgisi belirleyicidir. Kasko akışında ise teminat ve ek seçenek kararları devreye girer.
Ayrı akışlar sayesinde her branş yalnızca kendi sorularını sorar, kendi doğrulama kurallarını uygular ve sigorta şirketlerinden kendi sorgu yöntemiyle teklif alır.
Ayrışması Gereken Unsurlar
- Sigorta konusu bilgileri: Trafik ve kaskoda araç, DASK'ta bina ve adres.
- Sorgu adımları: Her branşın veri toplama ve sigorta şirketine iletme sırası kendine özgüdür.
- Doğrulama kuralları: Bir branşa ait kontrol diğer branşta tetiklenmemelidir.
- Sonuç ekranının içeriği: Karşılaştırılan teminatlar ve öne çıkan bilgiler branşa göre değişir.
Ortak Kalması Gereken Unsurlar
Kullanıcının bir branştan diğerine geçerken yeniden öğrenmek zorunda kalmaması için aşağıdaki unsurlar sabit tutulmalıdır:
- Sayfa iskeleti: Başlık alanı, ilerleme göstergesi, ana eylem düğmesinin yeri.
- Müşteri seçimi: Akışın başında müşteri her branşta aynı yöntemle seçilir veya oluşturulur.
- Bileşenler: Giriş alanları, açılır listeler, tarih seçiciler ve hata mesajları aynı görünüm ve davranışa sahiptir.
- Kaydetme davranışı: Taslak kaydetme, yarıda bırakma ve devam etme her branşta aynı çalışır.
- Sonuç ekranının yapısı: İçerik değişse de tekliflerin listelenme, sıralanma ve seçilme biçimi ortaktır.
Görsel İpuçlarıyla Bağlamı Korumak
Kullanıcı birden fazla teklif sekmesiyle çalışırken hangi branşta olduğunu anında görebilmelidir. Bunun için branşa özgü küçük bir ikon ve sayfa başlığında net bir branş adı yeterlidir. Branşları birbirinden ayırmak için tamamen farklı renk şemaları kullanmak ise tutarlılığı bozar; renk, yalnızca ince bir vurgu olarak kullanılmalıdır.
Ortak Veriyi Bir Kez Toplamak
Aynı müşteri için hem trafik hem kasko teklifi alınması sık rastlanan bir durumdur. Bu senaryoda müşteri ve araç bilgilerinin ikinci akışta yeniden istenmesi gereksiz bir tekrardır. İyi tasarlanmış bir sistemde:
- Müşteri bilgileri CRM kaydından gelir,
- Trafik akışında girilen araç bilgileri kasko akışına aktarılabilir,
- Kullanıcı bir teklif sonucundan diğer branşa "bu müşteri için kasko teklifi de al" gibi bir kısayolla geçebilir.
Bu aktarım yapılırken akışlar birleşmez; yalnızca ortak veri paylaşılır. Her akış kendi sorgusunu bağımsız olarak çalıştırır.
Sonuç Ekranlarında Branşa Özgü Öncelikler
Trafik teklif sonuçlarında kullanıcının ilk bakmak istediği bilgiler ile kasko sonuçlarında öne çıkan bilgiler aynı değildir. Kaskoda teminat kapsamı ve ek seçenekler karşılaştırmanın merkezindeyken, DASK sonuçlarında bina bilgilerinin doğruluğunun teyidi öne çıkar. Sonuç kartlarının iskeleti ortak kalırken kart içindeki öncelik sırası branşa göre ayarlanmalıdır.
Tasarım Sistemi ile Tutarlılığı Kalıcı Kılmak
Üç akışın zamanla birbirinden uzaklaşmaması için ortak bileşenlerin bir tasarım sistemi içinde yönetilmesi gerekir. Bir branşa yeni bir alan eklenirken yeni bir bileşen icat edilmez; mevcut bileşen kütüphanesinden seçilir. Böylece bir akışta yapılan iyileştirme, örneğin daha iyi bir tarih seçici, diğer akışlara da otomatik olarak yansır.
Mobil ve Web Arasında Aynı Mantık
Trafik, kasko ve DASK akışlarının ayrımı mobil uygulamada da korunmalıdır. Mobilde ekran alanı dar olduğundan akışlar daha fazla adıma bölünebilir; ancak adımların sırası ve isimleri web paneliyle aynı kalmalıdır. Sahada başlatılan bir DASK teklifi ofiste açıldığında kullanıcı aynı yapıyla karşılaşmalıdır.
Örnek Senaryo: Aynı Müşteri, Üç Ayrı Talep
Bir müşteri acenteyi arayarak aracının trafik sigortasını yenilemek istediğini, kasko fiyatını da merak ettiğini ve yeni taşındığı dairesi için DASK yaptırmak istediğini söylüyor. Kullanıcı önce müşteriyi CRM'den seçer ve trafik akışını başlatır. Araç bilgileri girildikten sonra teklifler gelirken, sonuç ekranındaki kısayolla kasko akışına geçer; müşteri ve araç bilgileri hazır gelir, yalnızca kaskoya özgü sorular sorulur. Ardından DASK akışını açar; bu kez araç bilgisi hiç görünmez, yeni adres ve bina bilgileri kademeli olarak girilir.
Kullanıcı bu süreçte üç farklı sorgu akışından geçer ama her birinde aynı düğme yerleşimini, aynı hata mesajı biçimini ve aynı kaydetme davranışını görür. Üç teklif de müşteri kartında ayrı kayıtlar olarak listelenir. Müşteri için tek bir görüşme, acente için üç bağımsız ve izlenebilir teklif ortaya çıkar.
Bu senaryo, ayrışma ile tutarlılığın birbirine rakip değil, birbirini tamamlayan ilkeler olduğunu gösterir.
Kontrol Listesi
- Her branş yalnızca kendi alanlarını gösteriyor mu?
- Kullanıcı hangi branşta olduğunu tek bakışta anlayabiliyor mu?
- Düğmeler, hata mesajları ve kaydetme davranışı branşlar arasında aynı mı?
- Ortak veri yeniden yazdırılmadan aktarılabiliyor mu?
- Bir branştaki bileşen değişikliği diğer branşları bozmadan uygulanabiliyor mu?
InsureHub teklif programında trafik, kasko ve DASK'ı ayrı sorgu akışları olarak ele alırken kullanıcıya tek bir tutarlı deneyim sunmayı hedefliyoruz. Akışları yakından görmek için demo talebi bırakabilirsiniz.