Bir arayüzü kullanılabilir kılan şey yalnızca düzeni ve görselliği değildir; ekrandaki kelimeler de en az onlar kadar belirleyicidir. Bir düğmenin üzerinde "Gönder" mi, "Teklif al" mı yazdığı, bir alan etiketinin "Kullanım tarzı" mı yoksa "Araç kullanım amacı" mı olduğu, kullanıcının ne yapacağını ne kadar hızlı anladığını etkiler. Arayüz metni yazımı, bu kelimelerin bilinçli olarak seçilmesi disiplinidir.
Sigorta sektörü yoğun bir terminolojiye sahiptir: teminat, muafiyet, zeyil, prim, hasarsızlık indirimi, rizikonun adresi... Acente çalışanları bu terimlere aşinadır, ancak yeni başlayanlar, yardımcı personel ya da müşteriye gösterilen ekranlar için durum farklıdır. Bu yazıda acente yazılımında arayüz metinlerini sade, tutarlı ve doğru yazmanın ilkelerini ele alıyoruz.
İlke 1: Eylemi Anlatan Düğmeler
Düğme metni, basıldığında ne olacağını söylemelidir. "Tamam", "Gönder" ya da "Devam" gibi genel ifadeler bağlam olmadan belirsiz kalır. Bunun yerine eylemin kendisi yazılmalıdır:
- "Gönder" yerine "Teklif iste",
- "Tamam" yerine "Poliçeyi kaydet",
- "Sil" yerine "Taslağı sil",
- "İleri" yerine "Araç bilgilerine geç".
Özellikle geri alınamayan işlemler için bu kural kritiktir. Kullanıcı düğmeye basmadan önce sonucun ne olacağını tam olarak bilmelidir.
İlke 2: Bir Kavram, Tek Bir Kelime
Aynı kavram için farklı ekranlarda farklı kelimeler kullanmak, kullanıcıda iki farklı şeyden bahsedildiği izlenimi yaratır. Bir ekranda "müşteri", diğerinde "sigortalı", bir başkasında "kişi" dendiğinde kullanıcı bunların aynı kayıt olup olmadığını sorgular. Sigortacılıkta sigortalı ile sigorta ettiren farklı kişiler olabildiğinden, terimlerin bilinçli ve tutarlı kullanılması daha da önem kazanır.
Bunun için bir terim sözlüğü hazırlanmalıdır. Sözlükte her terimin tanımı, arayüzde hangi biçimde kullanılacağı ve kullanılmaması gereken eş anlamlıları yer alır. Yeni bir ekran yazılırken bu sözlük referans alınır.
İlke 3: Sektör Terimini Koru, Gerektiğinde Açıkla
Sektör terimlerini tamamen kaldırmak doğru değildir; acente çalışanları bu terimlerle düşünür ve sigorta şirketleriyle bu terimlerle iletişim kurar. Doğru yaklaşım, terimi korumak ve gerektiğinde kısa bir açıklama sunmaktır. Bu açıklama, alanın yanında küçük bir yardım simgesi ya da alanın altında kısa bir yardımcı metin olabilir.
Örneğin kasko akışında bir muafiyet seçeneğinin yanında, muafiyetin ne anlama geldiğini bir cümleyle anlatan bir not yer alabilir. DASK akışında bina inşa yılının neden sorulduğunu belirten kısa bir açıklama, kullanıcının müşteriye doğru soruyu sormasına yardım eder.
Yardımcı metin yazarken
- Tek cümle yeterliyse ikinci cümleyi yazmayın,
- Örnek değer verin; örnek, tanımdan çoğu zaman daha hızlı anlaşılır,
- Yardım metnini alan etiketinin tekrarına dönüştürmeyin,
- Mevzuata dair kesin ifadeler gerekiyorsa, bu metni mutlaka uzman kontrolünden geçirin.
İlke 4: Kısa, Ama Belirsiz Değil
Arayüz metinlerinde kısalık önemlidir; ancak kısaltmak için anlamdan ödün verilmemelidir. "Pol. bşl. trh." gibi kısaltmalar alan kazandırır ama okunmayı zorlaştırır. Dar alanlarda bile "Başlangıç tarihi" gibi açık ifadeler tercih edilmeli, gerekirse yerleşim düzenlenmelidir. Herkesin bildiği kısaltmalar ise kullanılabilir; ancak bunlar da terim sözlüğünde tanımlanmalıdır.
İlke 5: Hata ve Uyarı Metinlerinde Yön Göster
Hata metinleri, kullanıcıya neyin yanlış gittiğini ve nasıl düzeltileceğini anlatmalıdır. Sistem tarafından üretilen teknik hata kodları kullanıcıya olduğu gibi gösterilmemelidir. Sigorta şirketinden dönen bir hata mesajı da, kullanıcının anlayabileceği bir dile çevrilerek ve mümkünse yapılabilecek bir sonraki adımla birlikte sunulmalıdır.
Örneğin "İşlem başarısız" yerine "Sigorta şirketinden yanıt alınamadı. Teklifi birkaç dakika sonra yeniden isteyebilir ya da diğer şirketlerin sonuçlarıyla devam edebilirsiniz." gibi bir ifade, kullanıcının durumu anlamasını ve iş akışını sürdürmesini sağlar.
İlke 6: Onay Metinlerinde Sonucu Netleştir
Bir kaydı silmek, poliçeyi iptal etmek ya da toplu işlem yapmak gibi önemli eylemlerden önce gösterilen onay pencereleri, çoğu zaman "Emin misiniz?" sorusuyla geçiştirilir. Bu soru kullanıcıya bir bilgi vermez. İyi bir onay metni, işlemin neyi etkileyeceğini somut olarak söyler: "Bu müşteriye ait 3 taslak teklif silinecek. Bu işlem geri alınamaz." Onay düğmesi de genel bir "Evet" yerine "Taslakları sil" şeklinde olmalıdır.
İlke 7: Ton Tutarlılığı
Arayüzün tonu, ürünün kişiliğini yansıtır. Acente yazılımında doğru ton genellikle profesyonel, sakin ve saygılıdır. Aşırı samimi ifadeler, espriler ya da ünlem işaretleri, özellikle hata durumlarında rahatsız edici olabilir. Hitap biçimi de tutarlı olmalıdır; bir ekranda "siz", diğerinde "sen" kullanılması dikkat çeker.
İlke 8: Müşteriye Giden Metinleri Ayrı Değerlendir
Acente yazılımından üretilen teklif belgeleri, bilgilendirme mesajları ve hatırlatmalar müşteriye ulaşır. Bu metinler, acente çalışanına yönelik arayüz metinlerinden farklı bir okuyucu kitlesine hitap eder. Müşteriye giden metinlerde teknik terimler daha fazla açıklanmalı, acentenin kendi kurumsal dili yansıtılmalıdır. Teklif belgelerinde yer alan ifadelerin, teminat ve koşulları yanlış anlaşılmaya yer bırakmadan aktarması özellikle önemlidir.
Metinleri Test Etmek
Arayüz metinleri de tasarımın diğer parçaları gibi test edilebilir. Kullanılabilirlik testlerinde kullanıcılardan bir düğmeye basmadan önce ne olacağını tahmin etmelerini istemek, belirsiz metinleri hızla ortaya çıkarır. Destek taleplerinde sıkça geçen "bu ne demek?" soruları da yeniden yazılması gereken metinlerin işaretidir.
Metin gözden geçirme listesi
- Düğme, basıldığında ne olacağını söylüyor mu?
- Kullanılan terim, sözlükteki karşılığıyla aynı mı?
- Sektör terimi gerekiyorsa açıklaması erişilebilir mi?
- Hata metni bir sonraki adımı gösteriyor mu?
- Onay metni işlemin sonucunu somut olarak anlatıyor mu?
- Ton ve hitap biçimi diğer ekranlarla tutarlı mı?
Kelimeler de Arayüzün Parçasıdır
Arayüz metinleri çoğu zaman tasarımın son aşamasında, geliştirici tarafından yer tutucu olarak yazılır ve öylece kalır. Oysa doğru seçilmiş kelimeler, ek bir eğitim ihtiyacını azaltır, hataları önler ve yazılıma duyulan güveni artırır. Metinlerin tasarım sürecinin başından itibaren ele alınması, tasarım sisteminde bileşenlerle birlikte belgelenmesi ve düzenli olarak gözden geçirilmesi gerekir.
InsureHub'da teklif ve CRM ekranlarındaki metinleri acente çalışanlarının günlük dilini esas alarak yazmayı hedefliyoruz. Ekranları kendi ekibinizin gözünden değerlendirmek için demo talebi oluşturabilirsiniz.