İş uygulamalarında destek taleplerini azaltan hata mesajları

Neden belirsiz hatalar daha fazla destek talebi yaratır

Belirsiz hatalar sadece can sıkıcı değildir. İnsanları görev ortasında durdurur ve kullanıcının bir sonraki adımı net olmaz.

Bir iş kullanıcısı genellikle bir uygulamayı “hata ayıklamaya” çalışmıyor. Bir form gönderip, bir isteği onaylayıp ya da bir müşteri kaydını güncellemeye çalışıyor. Mesaj “Geçersiz giriş” ya da “Erişim reddedildi” gibi olduğunda, kullanıcı neyi yanlış yaptığını, neyi değiştirmesi gerektiğini ya da kimin düzeltebileceğini anlayamaz.

Bu belirsizlik destek taleplerine dönüşür. Önce kullanıcı az detayla problemi bildirir. Sonra destek ekran görüntüleri, tam adımlar, düzenlenen kayıt ve olayın zamanı gibi bilgileri ister. Kullanıcı daha sonra cevap verir, genellikle çoktan konuyu bırakmış olur. Bu arada iş aksar.

Bu yüzden destek taleplerini azaltan hata mesajları eyleme odaklanır, suçlamaya değil. Ekranın karşısındaki kişinin sorunu hemen çözmesine yardımcı olur ya da en azından uzun bir yazışma olmadan doğru yere yönlendirir.

İş uygulamalarında en çok “takıldım” bileti yaratan iki hata türü vardır:

• Doğrulama hataları: Kullanıcı, girdiği veriyi değiştirerek düzeltebilir (zorunlu alan eksik, biçim yanlış, değer aralık dışında).
• İzin hataları: Kullanıcı tek başına düzeltemez çünkü erişim kontrol edilir (rol sınırlamaları, kayıt sahipliği kuralları, onay hakları eksik).

Bunlar kötü yazıldığında kullanıcıya aynı şekilde gelir. İkisi de çıkmaz gibi görünür.

Net bir mesaj kısa bir yol oluşturur. Birkaç pratik soruyu yanıtlar:

• Tam olarak ne yanlış (basit bir dille)?
• Sorun nerede (hangi alan, hangi kayıt, hangi adım)?
• Şimdi ne yapabilirim (düzelt, erişim iste, sonra tekrar dene)?
• Yardıma ihtiyacım olursa hangi detayları göndermeliyim?

Örnek: AppMaster gibi bir platformla oluşturulmuş iç bir araçta kullanıcı yeni bir tedarikçi oluşturmaya çalışıyor. “Hata 400” bir bilet gerektirir. “Vergi Kimliği 9 hane olmalı. Siz 8 girmişsiniz.” ise işi saniyeler içinde çözer.

Bu makale, iş kullanıcılarının özel erişim veya gizli yönetici bilgisine gerek kalmadan yaygın sorunları çözebilmeleri için doğrulama ve izin mesajlarının nasıl yeniden yazılacağını ele alıyor.

Doğrulama hataları vs izin hataları: kullanıcıların yaşadığı deneyim

Doğrulama hataları, kullanıcının girdiği verinin kabul edilemediği durumlarda ortaya çıkar. Kullanıcı doğru şeyi yapmaya çalışıyor, ancak bir alan eksik, biçim yanlış veya değer izin verilen aralığın dışında. İyi doğrulama mesajları yardımsever bir itme gibi gelir çünkü düzeltme genellikle aynı ekranda yapılır.

Yaygın doğrulama anları şöyle görünür:

• Zorunlu bir alan boş (ör. Müşteri adı)
• Bir değer yanlış biçimde girilmiş (e-posta, telefon, tarih)
• Bir sayı aralık dışında (indirim %100'ün üzerinde, adet 1'in altında)
• Metin çok uzun (notlar limitin üzerinde)
• Geçersiz bir seçim (izin verilmeyen bir durum)

İzin hataları farklıdır. Veri geçerli olsa bile kullanıcının bir şeyi yapmasına izin verilmediğinde ortaya çıkar. Bu, rol kısıtlamaları (gösterici vs yönetici), sahiplik kuralları (sadece kaydın sahibi düzenleyebilir) veya iş politikası (sadece finans iade yapabilir) yüzünden olabilir. Kullanıcı genellikle bunu tek başına düzeltemez, bu yüzden izin mesajları daha fazla hayal kırıklığı yaratabilir.

Kötü yazılmış izin hataları kişisel geliyormuş gibi hissettirebilir: “Erişim reddedildi” sistemin kullanıcıyı yargıladığı izlenimini verir, kuralı açıklamak yerine. Ayrıca ekranın hiçbir yerinde değişiklik görünmediği için kafa karıştırıcıdır. Kullanıcı dün aynı işlemi yaptıysa ve bugün başarısız oluyorsa uygulamanın bozuk olduğunu varsayar ve bir bilet açar.

En iyi mesaj, ona bakan kişiye bağlıdır. Son kullanıcı basit bir sonraki adımı ister: yerine ne yapabileceği veya kiminle iletişime geçeceği. Bir yönetici ise kuralı ve eksik izni bilmelidir ki rolleri güvenli şekilde değiştirebilsin. Takımların iş uygulamaları oluşturduğu araçlarda (örneğin AppMaster gibi rol tabanlı erişim olan platformlarda) bu ayrım önemlidir: bir mesaj kullanıcılar için gürültüyü azaltırken aynı zamanda yöneticilere sorunu çözmek için yeterli detayı verebilir.

Hata mesajlarını tasarlarken doğrulamayı “bunu şimdi siz düzeltebilirsiniz”, izinleri ise “bu neden engelleniyor ve en hızlı yol nedir” diye ele alın.

İş kullanıcılarının harekete geçebileceği hata mesajlarının ilkeleri

Destek taleplerini azaltan hata mesajları istiyorsanız, her mesajı küçük bir talimat seti gibi ele alın. Bir iş kullanıcısı bir kez okuyup neyi düzeltmesi gerektiğini bilmelidir; suçlanmış hissetmemelidir.

Önce ne olduğunu tek cümleyle sade bir şekilde açıklayın. Kullanıcıyı suçlayan ifadelerden kaçının. “Kaydı kaydedemedik” “Geçersiz veri girdiniz” demekten daha sakin hissettirir.

Sonra sorunun nerede olduğunu kesinleştirin. Tam alanı, kaydı veya adımı işaret edin. “Fatura tarihi” “Geçersiz giriş”den daha iyidir. Sorun belirli bir öğeyle ilgiliyse kullanıcı tanıyacağı bir tanımlayıcı ekleyin (sipariş numarası veya müşteri adı gibi).

Sonra bir net sonraki eylem verin. Kısa tutun ve uzun paragraf tavsiyelerden kaçının. Kullanıcılar sizin içsel mantığınızı değil bir sonraki en iyi hamleyi ister: bir değer seçmek, biçimi değiştirmek, erişim istemek veya yönetici ile iletişime geçmek.

Basit bir yapı kullanıcıların zamanla kalıbı öğrenmesini sağlar. Birçok ekip şu şablonu kullanır:

• Ne oldu (sade dil)
• Nerede (alan, kayıt, ekran veya adım)
• Sonraki ne yapılmalı (tek bir eylem)
• Engellenirse ne yapılmalı (kimi onaylayabilir veya nereden erişim istenir)

Spesifik, yaratıcı olandan iyidir. İç terimler, sistem kodları ve araç isimlerini kullanıcı zaten bilmiyorsa atlayın. “Durum şu seçeneklerden biri olmalı: Taslak, Onaylandı, Ödendi” “Enum doğrulaması başarısız oldu” demekten daha iyidir. Destek için bir referans eklemeniz gerekiyorsa sonuna koyun ve açıkça etiketleyin (ör. “Referans: 8F2A”), böylece dikkat dağıtmaz.

Tutarlılık aynı zamanda ton ve biçimlendirme açısından da önemlidir. Bir mesaj “Düzelt:” kullanırken diğer mesaj “Çözüm:” kullanırsa kullanıcı yavaşlar. Bir kalıp seçin ve tekrar kullanın.

İşte mesajları eyleme dönüştüren birkaç hızlı kontrol:

• Kullanıcının sözlerini kullanın, veritabanının terimlerini değil (Fatura e-postası yerine contact_email demeyin)
• 1–2 kısa cümle ve ardından eylem verin
• “Yanlış” veya “başarısız” gibi suçlayıcı kelimeler yerine “olamadı” veya “gerekli” gibi sözcükler kullanın
• Bir alan zorunluysa neyin zorunlu olduğunu ve görevin neden önemli olduğunu söyleyin
• Erişim eksikse genellikle hangi rolün ya da ekibin bunu sağlayacağını söyleyin

Doğrulama hatalarını yeniden yazın, kullanıcılar hızlıca düzeltsin

Doğrulama hataları destek taleplerini azaltmanın en kolay yeridir çünkü kullanıcı sorunu genellikle hemen düzeltebilir. Anahtar, “Geçersiz giriş” gibi belirsiz mesajları ne olduğunu, nerede olduğunu, nasıl düzelteceğini ve sonraki adımı açıkça yanıtlayan bir mesaja çevirmektir.

Her yerde işe yarayan basit bir şablon:

• Problem: ne yanlış
• Nerede: tam alan veya adım
• Düzeltme: insan dilinde kural
• Sonraki adım: kullanıcı düzelttikten sonra ne olacağı

“Düzeltme” kısmını somut tutun. İş kullanıcıları teknik terimler yerine örnekler, sayılar ve izin verilen biçimler ile daha iyi anlar.

İşte yaygın durumlar için yeniden yazımlar:

• Zorunlu alan: “Eksik bilgi: Fatura Tarihi. YYYY-AA-GG biçiminde bir tarih girin (örnek: 2026-01-25). Ardından Kaydet'e tıklayın.”
• Geçersiz biçim: “Telefon numarası biçimi tanınmadı: Müşteri Telefonu alanına sadece rakam girin, örn. 4155550123. Sonra tekrar deneyin.”
• Aralık dışı: “İndirim çok yüksek: İndirim % alanına 0 ile 30 arası bir değer girin. Ardından Uygula'ya tıklayın.”
• Yinelenen: “Bu e-posta zaten kullanılıyor: E-posta alanına farklı bir e-posta girin veya mevcut müşteri kaydını açıp güncelleyin.”

Dahil edilmemesi gerekenler: iç alan kimlikleri, regex, veritabanı hataları veya suistimal edilebilecek kurallar. Yine de hassas mantığı ortaya çıkarmadan yardımcı olabilirsiniz. Örneğin, “Parola politika v3'e uymalı” demek yerine “En az 12 karakter, en az bir sayı kullanın” deyin.

Mesajı göstereceğiniz yeri, kullanıcının aynı anda kaç sorunla karşılaşabileceğine göre belirleyin. Kullanıcı alanı yerinde düzeltebiliyorsa inline metin; çoklu alanı içeren sorunlar için tek bir banner kullanın.

Örneğin AppMaster gibi bir no-code oluşturucuda, zorunlu alanlar ve biçim hataları için her alanın yanında inline mesajlar en iyi sonucu verir; “Başlangıç tarihi bitiş tarihinden önce olmalı” gibi çoklu alan gerektiren durumlar için banner uygundur.

Bu yaklaşımı tutarlı uygularsanız, kullanıcıların tahmin etmeden veya yardım istemeden kendi kendine düzelttiği hata mesajları elde edersiniz.

İzin hatalarını hassas detayları açmadan yeniden yazın

İzin hataları zordur çünkü kullanıcılar yol gösterilme ihtiyacı duyar, fakat erişmemeleri gereken şeyleri sızdırmamak gerekir. Amaç “erişim reddedildi”yi net bir sonraki adıma çevirmek, mesajı nötr tutmak ve hassas detayları gizlemektir.

Önce kimlik doğrulamayı (authentication) yetkilendirmeden (authorization) ayırın. Kişi oturum açmamışsa (veya oturumu süresi dolmuşsa) bunu açıkça söyleyin ve oturum açma seçeneği sunun. Oturum açıksa ama yetkisi yoksa erişimi olmadığını söyleyin ve güvenli bir yol gösterin.

İşin nasıl yürüdüğüne uygun rol-dostu dil kullanın. Çoğu iş kullanıcısı “403” veya “politika değerlendirmesi” gibi terimlerle düşünmez. Çalışma alanları, ekipler ve sahipler gibi terimlerle düşünürler.

Genellikle destek taleplerini azaltan izin mesajları için basit bir yapı işe yarar:

• Ne oldu: “Bu sayfaya/işleme erişiminiz yok.”
• Neden (yüksek seviyede): “Bu çalışma alanındaki rolünüz bu izne sahip değil.”
• Sonraki adım: “Çalışma Alanı Sahibi’nden erişim isteyin” veya “Farklı bir çalışma alanına geçin.”
• Yedek: “Yanlış olduğunu düşünüyorsanız yöneticinizle iletişime geçin.”
• Opsiyonel: “Referans ID: ABC123” (sadece destek kayıtlarını izlemeye yardımcı oluyorsa)

Hassas detayları dışarıda tutun. Belirli bir kaydın varlığını, kim tarafından sahiplenildiğini veya neden kısıtlandığını doğrulamayın. “Fırsat #48102 Finans departmanına ait” veya “Bu müşteri incelemeye alındı” gibi ifadeler veri sızdırabilir. Kısıtlı bir projenin adını göstermek bile sızıntı olabilir.

Kötü: “M&A grubunda değilsiniz, ‘Edinme Planı 2026’ görünmüyor.”

Daha iyi: “Bu öğeye erişiminiz yok. Çalışma Alanı Sahibi’nden erişim isteyin veya izniniz olan bir çalışma alanına geçin.”

Bağlama göre doğru rotayı sunun. Uygulamanız birden çok çalışma alanı veya hesaba sahipse, “Çalışma alanını değiştir” genellikle en hızlı çözümdür. Rol sorunuysa “Erişim iste” “Destekle iletişime geç” demekten daha iyidir. AppMaster gibi kimlik doğrulama ve rol tabanlı erişim kurallarına sahip platformlarda bu, erişimin nasıl yönetildiğiyle paraleldir.

Yalnızca zaman kazandırıyorsa referans ID ekleyin. Destek sunucuları günlükleri olmadan teşhis yapamıyorsa kısa bir ID faydalıdır. Kullanıcı kendisi çözebilecekse (yanlış çalışma alanı, eksik rol) ek kod sadece gürültü ekler.

Kısa örnek: Maria “Ödemeler Raporunu Dışa Aktar”a tıklar ve şu mesajı görür: “Çalışma Alanı: Perakende Operasyonları'nda rapor dışa aktarma izniniz yok. Çalışma alanını değiştirin veya Çıktı Alma rolünü Çalışma Alanı Sahibinden isteyin.” Maria “Merkez Finans” çalışma alanına geçer ve dışa aktarımı hiçbirine ihtiyaç duymadan tamamlar.

İzin mesajlarında ne olmalı (ve ne olmamalı)

Bir izin hatası hızlıca şu soruyu yanıtlamalı: “Bir sonraki ne yapabilirim?” Mesaj sadece “Erişim reddedildi” diyorsa, çoğu kişi tekrar denemeye, yenilemeye veya farklı cihaz kullanmaya çalışır. Bunların hiçbiri izinleri değiştirmez ve bu da destek talebine dönüşür.

İş kullanıcısının kendi kendine düzeltebilmesini sağlayacak asgari detayları verin. Engellenen eylemi sade dilde adlandırın, sonra basit bir neden verin. “Faturaları onaylayamazsınız” “403 Yasak” demekten daha açıktır. Sorun rol tabanlıysa bunu belirtin: “Rolünüzde fatura onayı yok.”

Ayrıca kimlerin bunu açabileceğini söyleyin ama riskli detayları sızdırmayın. Birçok ekipte belirli bir kişiyi adlandırmak uygundur; bazen bu organizasyon yapısını açığa çıkarabilir veya istenmeyen bildirimlere yol açabilir. Güvenli varsayılan, bir rol veya gruba yönlendirmektir: “Çalışma Alanı Yöneticisine sor” veya “Hesap Sahibi ile iletişime geç.”

İyi bir izin mesajı genellikle şunları içerir:

• Engellenen eylem (görüntüle, düzenle, dışa aktar, sil, onayla)
• Basit bir neden (rol eksik, bu kayda atanmamış, özellik kapalı)
• En güvenli sonraki adım (erişim iste, farklı iş akışı seç, taslak olarak kaydet)
• Ne işe yaramayacağına dair bir ipucu (tekrar denemek erişimi değiştirmez)
• Kısa, nötr bir ton (suçlama yok, alay yok)

Çıkarmanız gerekenler: iç kodlar, teknik yığın terimleri ve hassas erişim kuralları. “Finance-AP-Approvers grubunda değilsiniz” gibi grup isimleri özel yapıyı ifşa edebilir. Kayıt kimlikleri, kullanıcı kimlikleri veya “atlatma” ipuçları eklemeyin. Bu ayrıntıları destek için sunucu günlüklerinde tutun, ekranda değil.

Bir net seçenek ekleyin. Uygulamanız destekliyorsa “Erişim iste” butonu ideal çünkü bağlamı yakalar. AppMaster gibi platformlarda bunu basit bir iş akışına yönlendirip bir istek kaydı oluşturabilir, ilgili yöneticiye bildirim atabilir ve durumu takip edebilirsiniz.

Mesajın uygulama genelinde tutarlı olmasını sağlayın. Kullanıcılar kalıpları öğrenir. Her izin hatası aynı biçimi takip ederse kullanıcı tahminde bulunmayı bırakır ve doğru adımı atar.

Örnek dönüşüm:

“İzin reddedildi.”

Şunun gibi olur:

“Bu raporu dışa aktaramıyorsunuz çünkü rolünüzde dışa aktarma izni yok. Tekrar denemek erişimi değiştirmez. Rolünüz için ‘Rapor Dışa Aktarma’ iznini Çalışma Alanı Yöneticinizden isteyin veya erişim talep edin.”

Adım adım: uygulamanız için bir hata mesajı el kitabı oluşturun

Bir el kitabı, uygulamanızın gösterdiği hataların basit bir kataloğudur; tutarlı yazılmış ve güncel tutulur. İyi yapıldığında, destek taleplerini azaltan hata mesajlarına ulaşmanın en hızlı yoludur.

1) Hataların gerçekten nerede oluştuğunu haritalayın

Veritabanı tablolarınızdan değil kullanıcı yolculuğundan başlayın. İş kullanıcıları için en çok tıkanma yaratan birkaç eylemi seçin: kayıt oluşturma, bir isteği onaylama, rapor dışa aktarma ve geri alınamayan silme işlemleri. Her eylem için kullanıcı nerede duraklıyor, tekrar deniyor veya yardım istiyor not edin.

Hatanın tam olarak hangi anda ortaya çıktığını yazın (ör. “Onayla'ya tıklarken” vs “formda”), çünkü aynı problem adım farklı olduğunda farklı ifadeler gerekir.

2) Gerçek insanlardan gelen hataları toplayın

Taslakla başlamayın; toplayarak başlayın. Destek biletleri, sohbet mesajları ve kullanıcıların paylaştığı ekran görüntülerinden örnekler çekin. Orijinal metni saklayın, ne kadar çirkin olursa olsun. Düzeltmeniz gereken kalıpları gösterir.

AppMaster gibi bir platformla geliştiriyorsanız, uygulamanızdaki mevcut doğrulama ve izin mesajlarının bir listesini dışa aktarın ve bunu bilet havuzuyla karşılaştırın. Boşluklar önceliklerinizdir.

3) Mesajları niyete göre gruplayın (yazım tutarlı kalsın diye)

Yüzlerce benzersiz mesaj yerine birkaç net kategori oluşturun ve onları standardize edin. Yaygın kategoriler:

• Eksik veri (zorunlu alan boş)
• Çelişen veri (iki alan eşleşmiyor, yinelenen değer)
• Politika tarafından engellendi (zaman penceresi, durum kuralları, onay limitleri)
• Rol nedeniyle engellendi (kullanıcı izne sahip değil)
• Sistem sorunu (zaman aşımı, hizmet kullanılamıyor)

Niyetine göre gruplayınca yapı, ton ve “sonraki adım”ı yeniden kullanabilirsiniz.

4) Her vaka için bir standart mesaj yazın, sonra güvenli varyasyonlara izin verin

Her kategori için bir “altın” mesaj şablonu oluşturun ve yalnızca değişmesi gerekenleri değiştirin: alan adı, izin verilen biçim, mevcut durum veya kim onaylar. Lokalizasyon gerekiyorsa, standart belirlendikten sonra çevirin.

Her mesajı: ne oldu, neden oldu (kullanıcı terimleriyle) ve en güvenli sonraki adım şeklinde tutun.

5) Sahipler ve gözden geçirme kuralları atayın

Bir mesaj kataloğu sahibi olmazsa bozulur. Karar verin:

• Kataloğu kim düzenler (genellikle Ürün veya UX)
• Kim onaylar (destek lideri + güvenlik, izinler için)
• Güncellemeler ne zaman yapılır (yayın kontrol listesi)
• Değişiklikleri nasıl izlersiniz (sürümlenmiş doküman)
• Etki nasıl ölçülür (bilet etiketleri, en çok görülen hata sayımları)

Amaç basit: her yeni özellik, kullanıcıların sorunu kendi başına çözmesini sağlayan mesajlarla piyasaya sürülmelidir.

Sessizce destek taleplerini artıran yaygın hatalar

Bazı destek talepleri sert hatalardan kaynaklanmaz. Mesaj kullanıcının bir sonraki adımı atmasına yardım etmediği için oluşur. Küçük bir ifade seçimi 10 saniyelik bir düzeltmeyi uzun bir yazışmaya dönüştürebilir.

Bunlardan biri, beklenen ve düzeltilebilir sorunlar için genel metin kullanmaktır. “Bir şeyler ters gitti” bir kesinti için anlamlı olabilir, ama eksik zorunlu alan için sinir bozucudur. Muhtemel nedeni biliyorsanız, basitçe söyleyin ve düzeltilecek yeri işaret edin.

Diğer yaygın hata gerçek nedeni teknik terimlerin arkasına gizlemektir. “Exception”, “stack trace” veya “HTTP 403” doğru olabilir, ama iş kullanıcıları bunla hareket edemez. Teknik bir kod gerekiyorsa bile bunu insan açıklamasından ayrı ve ikincil tutun.

Sessiz bir bilet üreteci, kullanıcıya ilk ve tek seçenek olarak “Destek ile iletişime geçin” demektir. Mesaj doğrudan “Destekle iletişime geç” diyorsa kullanıcı tam da bunu yapar, hatta düzeltmesi basit olsa bile. Önce kendi kendine çözüm yolları sunun, sonra destek bir geri dönüş yolu olsun.

Ton da ekiplerin beklediğinden daha fazla önem taşır. Kullanıcıyı suçlayan mesajlar (“Yanlış veri girdiniz”) sürtünme yaratır ve insanların yeniden denemeye çekinmesine neden olur. Daha iyi ifade, eksik olanı, gereken biçimi ve sonraki adımı vurgular.

Son olarak, tutarsızlık kafa karışıklığı yaratır ve bunu kullanıcı hatası gibi görünen bir UI borcuna çevirir. Bir ekranda “çalışma alanı” denirken başka yerde “ekip” veya “hesap” denmesi kullanıcıların neyin kastedildiğini anlamasını zorlaştırır. Ürününüzdeki ana isimleri standartlaştırın ve her yerde tekrar kullanın, özellikle hata mesajlarında.

Hızlı bir hata kontrol listesi:

• Beklenen doğrulama sorunları için genel mesajlar kullanmak
• Teknik jargon yerine sade neden ve çözümler
• “Destekle iletişime geç”i tek seçenek yapmak
• Suçlayıcı dil kullanmak yerine yol gösterici dil
• Ekranlar arasında aynı kavram için farklı terimler kullanmak

AppMaster gibi platformlarda uygulama geliştiriyorsanız, UI'da tutarlı bir adlandırma sistemi tutarak ve ortak doğrulamalar ve izin kontrolleri için yeniden kullanılabilir hata metinleri yazarak bu sorunların çoğunu önleyebilirsiniz. Küçük değişiklikler bile gerçek anlamda destek talebi azaltımı sağlar, temel mantığı değiştirmeden.

Örnek: bir iş kullanıcısı desteğe ihtiyaç duymadan sorunu çözer

Maya Operasyon departmanında çalışıyor. İç bir sipariş aracında, Sipariş #10482'nin bugün sevk edilmesi için Onayla butonuna tıklıyor. Şu mesaj çıkıyor:

Orijinal (yararsız): Hata: Erişim reddedildi.

Maya sistemin çöktüğünü mü, yanlış düğmeye mi bastığını veya bir yöneticiye mi ihtiyacı olduğunu bilmez. En hızlı yol bir destek bileti açmaktır: “Siparişleri onaylayamıyorum. Lütfen düzeltin.” Destek her seferinde aynı soruyu sorar: “Hangi roldesiniz? Hangi çalışma alanındasınız? Hangi adımda?”

Şimdi bunu hassas detayları koruyan geliştirilmiş bir mesajla karşılaştıralım:

Geliştirilmiş (eylem odaklı): Mevcut rolünüzle Depo A'da siparişleri onaylayamazsınız.

Ne yapabilirsiniz:

• Bu siparişi onaylaması için bir Sipariş Yöneticisinden isteyin, veya
• Yöneticinizden Sipariş Onaylama iznini isteyin.

Referans: PERM-APPROVE-ORDER

Bu mesajla Maya tahmin etmek zorunda kalmaz. Üç basit şey yapar:

• Sipariş başlığını kontrol edip gerçekten Depo A için olduğunu doğrular.
• Depo için Sipariş Yöneticisine hızlıca haber verir.
• Erişim talebine referans kodunu (PERM-APPROVE-ORDER) ekler ki yönetici neyi değiştireceğini bilsin.

Bir dakika sonra yönetici siparişi onaylar. Maya tekrar dener ama form bu sefer onu farklı bir nedenle durdurur: fatura numarası boş.

Orijinal (yararsız): Doğrulama başarısız.

Bu genellikle başka bir bilet yaratır: “Doğrulama başarısız diyor. Bu ne demek?” Bunun yerine geliştirilmiş mesaj alanı işaret eder ve “iyi” örneği gösterir:

Geliştirilmiş (eylem odaklı): Onaylamak için Fatura numarası gereklidir.

Fatura numarası alanına ekleyin (örnek: INV-10482), ardından tekrar Onayla'ya tıklayın.

Maya e-postadan fatura numarasını kopyalar, alana yapıştırır ve başarıyla onaylar.

İşte destek taleplerini azaltan hata mesajlarının gerçek hayatta nasıl çalıştığı: “bir şeyler ters gitti”yi net bir sonraki adıma çevirir. Destek hâlâ gerçek uç durumlarda yardımcı olur, ama “Neden engellendim?” ve “Hangi alan yanlış?” gibi tekrarlayan soruları daha az görürler, çünkü uygulama sorunu olduğu yerde yanıtlıyor.

Hızlı kontroller ve sonraki adımlar

Değişiklikleri yaymadan önce, en çok yazışma yaratan hatalar için hızlı bir kontrol yapın. Hedef, kullanıcıya hatayı ilk gördüğünde düzeltmeyi bariz kılacak mesajlardır.

Hızlı kontrol listesi: doğrulama hataları

Doğrulama, insanların tam olarak neyi değiştirmesi gerektiğini söylemeli ve bunu değiştirebilecekleri yerde göstermelidir.

• Tam alanı adlandırın ve işaretleyin (girdiyi vurgulayın, mesajı yakın tutun).
• Neyin izinli olduğunu söyleyin (biçim, uzunluk, aralık, "YYYY-MM-DD kullanın" gibi örnekler).
• Kısa ve sade bir düzeltme verin ("kısıtlama" veya "şema" gibi teknik terimler kullanmayın).
• İzinli değerler varsa gösterin (veya en sık kullanılan birkaçını ve geri kalanını nasıl bulacaklarını).
• Belirsiz değil, spesifik olun ("Telefon numarası girin" "Geçersiz giriş" demekten daha iyidir).

Hızlı kontrol listesi: izin hataları

İzin mesajları ne olduğunu açıklamalı, hassas detayları ifşa etmemelidir.

• Engellenen eylemi belirtin ("Bu faturayı onaylayamazsınız").
• Güvenli bir neden verin ("Rolünüzde onay yok").
• Kim yardım edebileceğini söyleyin (çalışma alanı sahibi, departman yöneticisi veya "Finans Yöneticisi" gibi rol adları).
• Bir sonraki en iyi adımı sunun (erişim iste, farklı iş akışı seç, taslak olarak kaydet).
• Kullanıcının çalışmasını güvenli tutun (değişiklikleri atmayın; kaydedilip kaydedilmediğini doğrulayın).

Ekranlar arasında bir tutarlılık kontrolü yapın. Aynı şey için aynı terimleri kullanın (rol vs erişim, proje vs çalışma alanı), aynı tonu ve aynı yapıyı koruyun. Küçük uyuşmazlıklar insanların duraklamasına sebep olur.

3–5 teknik olmayan kullanıcı ile test edin. Onlara birkaç kasıtlı sorun verin ve sessiz kalın. Hangi kelimeleri tekrar ettiklerini, nerede durakladıklarını ve neye tıkladıklarını not edin. Hâlâ tahmin yapıyorlarsa yeniden yazın.

Sonraki adımlar: uygula, ölç ve yinele. İlk hafta en çok bilet yaratan 5 hatayla başlayın ve sadece onları iyileştirin. Eğer iç araçları AppMaster ile geliştiriyorsanız, alan düzeyinde doğrulama geri bildirimleri ve net izin engelleri göstermek için UI oluşturucularını ve İş Süreçlerini kullanın; sonra kurallar değiştikçe mantığı güncelleyin.