Erişim-engellendi UX desenleri ve metinleri: kullanıcıların hızlıca erişim istemesini sağlayın, bilgi sızıntısını önleyin ve net sonraki adımlarla destek biletlerini azaltın.
Bir izin duvarına çarpmak kişisel algılanır. İnsanlar bir şeyi yanlış yaptıklarını, hesaplarının bozulduğunu veya yanlış bir şeye tıkladıkları için başlarının belaya gireceğini varsayar.
Bu karışım —kafa karışıklığı, korku ve hayal kırıklığı— kullanıcıları en hızlı işe yarayabilecek şeye yönlendirir: bir bilet açmak, bir yöneticiye mesaj atmak ya da bir şey açılana kadar tıklamak.
Genel “403” sayfaları bilet fabrikası gibidir çünkü kullanıcıların gerçekten sordukları soruların hiçbirine cevap vermezler. İnsanlar sorunun geçici olup olmadığını, doğru yerde olup olmadıklarını ve bir sonraki adımın ne olduğunu bilmek ister. Ekran sadece bir kod gösterdiğinde destek, “Neye erişmeye çalışıyordunuz?” veya “Hangi hesabı kullanıyorsunuz?” gibi takip soruları sormak zorunda kalır ve yazışma başlar.
İyi bir erişim-engellendi UX, sınırlı bilgi sızdırmadan kullanıcıları yönlendirerek biletleri azaltır. Durumu net olarak belirtebilir ve korunan içeriğe dair belirsizlik koruyabilirsiniz. Örneğin, erişimin sınırlı olduğunu ve genel olarak hangi tür iznin gerektiğini (rol, ekip, proje) doğrulayabilirsiniz; sayfa başlıkları, kayıt isimleri veya kimin erişimi olduğu gibi ayrıntıları ifşa etmeyin.
İyi tasarlanmış bir ekran sessizce dört işi yapar:
Başarı, daha az “erişim sağlayamıyorum” bileti, daha hızlı onaylar ve artan güven demektir. Kullanıcılar engellenmiş yerine yönlendirilmiş hisseder; yöneticilerse ihtiyaç duydukları ayrıntılarla temiz talepler alır.
Eğer dahili araçlar veya portallar geliştiriyorsanız ve AppMaster kullanıyorsanız, erişim-engellendi durumlarını akıştaki gerçek bir ekran olarak ele alın, çıkış yolu değil. Bu günlük işlerin kritik yolunda yer alır.
Çoğu “erişim engellendi” anı kullanıcının bir şeyleri yanlış yapmasıyla ilgili değildir. Ürününüzün uygulamak zorunda olduğu bir kuralın içine takılmışlardır. İyi bir erişim-engellendi UX, durumu isimlendirir ama hassas hiçbir şeyi ifşa etmez.
İnsanların engellendiği yaygın, korkutucu olmayan nedenler:
Kafa karıştıran büyük bir kaynak, kimliksizlik (unauthenticated) ile yetkisizlik (unauthorized) arasındaki farktır. Kimliksizlik “henüz kim olduğunuzu bilmiyoruz” demektir (oturum açılmamış, oturum süresi dolmuş). Yetkisizlik ise “kim olduğunuzu biliyoruz ama bu hesap bu alana erişemez” demektir. Bu durumların farklı sonraki adımları olmalıdır.
Bazı engeller geçici, bazıları kalıcıdır. Geçici engeller oturum zaman aşımı, bekleyen onaylar veya yeniden gönderilebilecek bir davet gibi olabilir. Kalıcı engeller bir politika kuralı, kaldırılmış bir rol veya basitçe o özelliğin mevcut olmaması olabilir. Geçici mesajlar tekrar giriş için açık bir yol göstermeli; kalıcı mesajlar nazik, kesin ve doğru sahipleneni işaret etmelidir.
Hangi eylemi göstereceğinizi seçerken basit tutun:
Bir erişim-engellendi ekranının iki görevi vardır: veriyi korumak ve kullanıcıyı serbest bırakmak. Risk yaratmanın en kolay yolu duvarın arkasında ne olduğunu yanlışlıkla doğrulamaktır.
İyi bir varsayılan basittir: “Bu sayfayı görüntüleme izniniz yok.” Bu ne olduğunu söyler ama kullanıcının neredeyse gördüğünü ifşa etmez.
İzin hata mesajını güvenli tutacak pratik kurallar:
Yine de destek biletlerini azaltacak kadar bağlam verebilirsiniz. Bağlamı genel tutun (nesne düzeyi değil sayfa düzeyi) ve sonraki eylemlere odaklanın.
Güvenli ifade örnekleri:
Somut bir örnek: biri iç müşteri kaydına ait paylaşılan bir bağlantı yapıştırır. İzin hata mesajı “Customer: Acme Corp” veya “Kayıt bulundu” dememelidir. Sadece sayfayı görüntüleyemeyeceğini söylemeli ve açık bir erişim isteği akışı sunmalıdır. Bu, erişim-engellendi UX'inizin yardımcı olmasını sağlar ve veri açıklama aracına dönüşmesini engeller.
Çoğu destek bileti, mesajın çıkmaz gibi hissettirmesinden başlar. İyi bir erişim-engellendi UX metni iki şey yapar: ne olduğunu sade bir dille onaylar ve kullanıcıya ne yapması gerektiğini söyler.
İnsan diliyle açık bir başlıkla başlayın. “Erişiminiz yok” teknik ve suçlayıcı olmayan bir açıklama sunduğu için “403 Forbidden”dan daha iyidir.
Ardından “Bunu nasıl düzeltirim?” sorusunu cevaplayan kısa bir cümle ekleyin. Spesifik olun, ama kısıtlı ayrıntıları sızdırmayın. Kaynak sahibi, gereken tam rol veya sayfanın var olup olmadığı gibi şeyleri adlandırmaktan kaçının.
Aksiyon-öncelikli butonlar kullanın. Birincil eylem kullanıcının ilerlemesini sağlamalı, ikincil eylem şu an erişim mümkün değilse yardımcı olmalı.
Tekrar kullanılabilecek ve uyarlanabilecek metin blokları:
Tonu nötr ve suçlamayan tutun. “Yetkili değilsiniz” veya “Kısıtlı bir kaynağa erişmeye çalıştınız” demeyin; bu kullanıcıyı yanlış bir şey yapmış gibi gösterir.
AppMaster ile uygulamalar inşa ediyorsanız, bunu tutarlı tutmak için tek bir yeniden kullanılabilir erişim-engellendi ekran bileşeni oluşturmak işinizi kolaylaştırır. Kullanıcı her yerde aynı sonraki adımları görür.
Bir erişim-engellendi ekranı hızlıca şu soruyu yanıtlamalı: şimdi ne yapabilirim? Sayfa engelliyse, insanları bir hataya bakakalmak yerine yönlendirin. Onlara bir açık ilerleme yolu ve güvenli bir yedek sunun.
Tüm engellenmiş durumlarda ana butonu aynı yapın: Request access. Formu kısa tutun ki kullanıcılar gerçekten kullansın. Onaylayıcı için yardımcı olacaksa gerekçeyi isteyin, ama isteğe bağlı yapın.
İşleyen basit bir düzen:
Bu, “ne yapmalıyım?” biletlerini azaltır ve kullanıcıyı ürün içinde tutar.
Bazen kullanıcılar erişim isteğinde bulunamaz (çalışma alanı yok, onaylayıcı yapılandırılmamış veya harici bir bağlantı). Bu durumda, kısıtlı ayrıntıları ifşa etmeden doğru kişiyi işaret eden bir fallback gösterin: Contact workspace admin (veya bu güvenliyse bir ekip adı).
Eğer dürüstçe söyleyebiliyorsanız beklenti ekleyin: “Çoğu istek 1 iş günü içinde yanıtlanır.” Söyleyemiyorsanız tahminde bulunmayın. “İncelendiğinde sizi bilgilendireceğiz” gibi nötr bir ifade kullanın.
Birden fazla hesabı olan kullanıcılar için “Switch account” seçeneği ekleyin. Birçok erişim sorunu sadece yanlış oturumdur.
Kullanıcıların bilete yapıştırabileceği güvenli bir destek snippet'i ekleyin: bir referans ID ve zaman damgası. Örnek: “Ref: 8F3K2, 2026-01-29 14:12 UTC.” Destek olayı kullanıcı açıklaması istemeden bulabilir.
Mesajı genel tutun. Kullanıcı sayfanın adını tahmin etmiş olsa bile UI bunu doğrulamamalı. Amaç ayrıntılı bir hata hikayesi değil bir sonraki adımda netlik sağlamaktır.
İyi bir erişim-isteği akışı bir çıkmazı açık bir sonraki adıma çevirir. Amaç basit: kullanıcıyı, göremediği şeyin ne olduğuna dair ipucu vermeden engelini kaldırmak. Doğru yapıldığında, erişim-engellendi UX destek biletlerini azaltır çünkü insanlar kiminle ve ne söyleyeceklerini tahmin etmeyi bırakır.
Herhangi bir mesajı göstermeden önce ne olduğunu sınıflandırın. Aynı “erişim yok” sonucu çok farklı şeyler anlamına gelebilir: oturum açılmamış, yanlış hesapta/organizasyonda, rol eksikliği veya özellik devre dışı.
Durumu bildiğinizde ona uygun ekranı seçin:
İstek, onaylayıcının karar vermesine yardımcı olacak kadar bilgi almalı: kullanıcı neyi denedi, nerede oldu ve kim olduğu. Sayfa alanı, çalışma alanı, zaman damgası ve cihaz gibi detayları otomatik doldurun. Bağlam için kısa isteğe bağlı bir not bırakın.
Gönderimden sonra hemen onay verin ve beklenti belirleyin. Kullanıcılar kimin inceleyeceğini, ne zaman haber alacaklarını ve bu arada ne yapabileceklerini bilmek ister.
Kullanıcıların tekrar göndermesini önlemek için küçük bir durum seti takip edin:
Örnek: biri kaydedilmiş bir bağlantıdan iç bir sayfaya açılmaya çalışırsa, “403” yerine “Mevcut rolünüzle bu sayfaya erişemezsiniz” ve sayfa kimliğini otomatik gönderen bir “Request access” eylemi gösterin. Rol tabanlı erişim arayüzlerinde bu “bağlamı benim için gönder” davranışı destek yazışmalarını başlatmadan durdurur.
İyi bir onay deneyimi, erişim-engellendi UX'in bitiş noktasından başlar. Kullanıcılar ne yapacaklarını bilmeli; onaylayıcılar uzun sohbet dizileri olmadan karar verebilmelidir.
İstek formunu kısa ve güvenli tutun. Onaylayıcının karar vermesine yardımcı olacak bilgileri sorun, ama kısıtlı sayfa isimlerini veya kayıt ayrıntılarını tekrarlamayın.
Şunları dahil edin:
Yönetici tarafında onayları bir adımda yapabilecek şekilde tasarlayın. Tek tıkla onay/red ideal, kısa bir sebep şablonu onaylama sürecini hızlandırır. Örnekler: “Ekibinizin kapsamına ait değil”, “Yönetici onayı gerekli”, “Ortak gösterge panosunu kullanın.”
Sade durum ifadeleri kullanın ve kullanıcı her baktığında güncel durumu gösterin:
“Kayıt güvenlik için tutuldu” gibi küçük bir not yeterlidir. Tehdit edici dil kullanmaktan kaçının. Kim istekte bulundu, kim onayladı, zaman damgalarını ve nedeni saklayın, ama istek sahibine hassas ayrıntıları gösterme.
Bildirimler için sadece güvenli bağlam gönderin: istek ID'si, durum ve sonraki eylem. E-posta veya sohbet bildirimleri (örneğin Telegram) iyi çalışır; mesaj kısıtlı sayfa başlığı veya özel veri içermediği sürece uygundur.
Çoğu “izin reddi” problemi izinlerle ilgili değil; ekranın insanların ne yapmasını sağladığıyla ilgilidir. Küçük bir metin değişikliği çok sayıda bileti azaltabilir.
Yaygın bir hata, kullanıcı açamadığı şeyi adlandırmaktır: “Fatura #4932” veya başlıkta bir müşteri adı gibi. Bu varlığın onaylandığını ve hassas verinin açığa çıktığını gösterir. Başlıkları genel tutun (“Kısıtlı sayfa”) ve tanımlayıcıları sadece onaylayıcı tarafında tutun.
Bir diğer tuzak, eksik olan tam rolü söylemektir: “FinanceAdmin gerekli.” Bu yardımcı gibi görünse de saldırganlara hedef verir ve normal kullanıcıları şaşırtır. Bunun yerine hangi tür erişimin gerektiğini sade terimlerle söyleyin (“Finans onayı gerekli”) ama dahili rol adını yazmayın.
Tek düğme “Destek ile iletişime geç” ve kullanıcıya bilet için önceden doldurulmuş bağlam vermemek biletleri artırır. Kullanıcının doğru ayrıntıları toplamasını sağlayan yönlendirilmiş bir eylem sunun.
Dikkat edilmesi gereken desenler:
Kısa bir gerçeklik kontrolü: biri paylaşılan bağlantıya tıklar, reddedilir, erişim ister ve sonra aynı reddedilme ekranına geri düşerse, hiçbir şey olmadığını varsayar ve desteğe yazar. Her zaman isteğin gönderildiğini doğrulayın ve sonraki adımda ne olacağını gösterin (kim inceleyecek, durum nereden kontrol edilir).
Bir satış temsilcisi, Maya, bir meslektaşından şu mesajı alır: “Görüşmeden önce müşterinin portal ayarlarını bu bağlantıyla incele.” Toplantıdan beş dakika önce telefonunda tıklar.
Portal sayfası yerine erişim-engellendi ekranına gelir. İyi bir erişim-engellendi UX hangi müşteri olduğu, hangi ayarlar veya sayfanın var olup olmadığı hakkında bilgi vermez. Maya için tek doğrulama şudur: Maya oturum açmış ama mevcut erişimi bu işlemi yapmaya yetmiyor.
Maya'nın gördüğü şeyler:
Maya “Request access”e dokunduğunda, sorunu baştan anlatmak zorunda kalmaz. Form güvenli ayrıntılarla otomatik doldurulur: sayfa alanı (“Customer portal”), eylem (“Görüntüle”), mevcut rolü ve isteğe bağlı kısa bir not kutusu.
Yönetici tarafında onaylayan, kim istediğini, hangi tür izne ihtiyaç duyulduğunu ve Maya’nın notunu görür. Kısıtlı sayfa başlığını veya müşteri adını görmez — eğer yönetici zaten erişime sahipse o zaman bu ayrıntılar görünür.
Sonuç: yönetici onaylar, Maya bildirim alır, “Sayfayı aç”a dokunur ve işine devam eder. Destek bileti açılmaz.
Eski tasarımda bilet oluşturacak olan şey: belirsiz bir “403 Forbidden,” istek düğmesi yok ve Maya'yı ekran görüntüleri ve tahminlerle desteğe yönlendiren bir çıkmaz.
İyi bir erişim-engellendi UX hassas ayrıntıları korur ve kullanıcıyı varsayım yapmadan bir sonraki adımı atmaya yardımcı olur.
Pratik bir test: kısıtlı bir bağlantıyı farklı bir hesaba yapıştırın ve ekranın hangi ayrıntıları açığa çıkardığını görün. Bir yabancı sayfanın arkasında ne olduğunu tahmin edebiliyorsa, o ayrıntıyı kaldırın ve yalnızca onaylayıcı tarafına taşıyın.
Yeni erişim-engellendi UX'iniz canlıya alındığında, insanların ilerleyip ilerlemediğini ve gereksiz gürültü oluşturup oluşturmadığını ölçün. Spesifik kısıtlı kayıtları tanımlamaktan kaçının; eğilimlere ve tıkanıklıklara odaklanın.
Hacim ve konumla başlayın. Erişim-engellendi ekranlarının ne sıklıkta göründüğünü, genel alanlara göre gruplanmış şekilde (ör. “Raporlar”, “Faturalama”, “Admin ayarları”), cihaz türü ve giriş noktası (menü, arama, paylaşılan bağlantı) ile takip edin. Eğer belirli sayfa isimleri veya öğe ID'leri hassas yapıyı açığa çıkaracaksa bunlardan kaçının.
Genellikle durumu anlatan temel metrikler:
Sayılarla yetinmeyin. Hızlı çözüm getirebilecek kalıplar arayın. Birçok kişi paylaşılan bir bağlantıdan reddediliyorsa sorun bağlantı paylaşma alışkanlıkları veya girişte eksik bağlam olabilir. Redlerin çoğu bir alanda toplanıyorsa, roller çok katı olabilir veya menünüz kullanılamayan hedefleri gösteriyor olabilir.
Analizi mümkün olduğunca anonim ve toplulaştırılmış tutun. Öğrendiklerinizi rol tanımlarını, yönlendirme ipuçlarını ve gezinme etiketlerini düzeltmek için kullanın.
Son olarak, küçük bir metin testi yapın. Sadece başlık ve birincil buton metnini değiştirin (örneğin: “Erişiminiz yok” vs “Devam etmek için erişim isteyin”, ve “Request access” vs “Yöneticiden iste”). Hangi versiyonun tekrar eden reddedilmeleri azalttığını ve tamamlanan istekleri artırdığını ölçün.
Küçük başlayın ve tutarlı kalın. İyi bir erişim-engellendi UX genellikle üç ekran durumu gerektirir; her biri bir net bir sonraki eyleme sahiptir:
Tasarımı yapmadan önce metni yazın. Mesaj net olduğunda düzen kendiliğinden belirgin olur: ne olduğunu açıklayan bir cümle, ne yapılacağını gösteren bir cümle ve bir birincil buton.
Her şeyi değiştirmeden hızlıca yayınlamak için akışı en çok bilet oluşturan yerde pilotlayın. Yaygın başlangıç noktaları bir yönetici paneli, müşteri portalı veya rollerin sık değiştiği bir iç araçtır.
Gün içinde tamamlanabilecek bir dağıtım planı:
AppMaster üzerinde (appmaster.io) inşa ediyorsanız, bunu yeniden kullanılabilir bir ekran ve basit bir istek/onay iş akışı olarak uygulayabilirsiniz; platformun görsel UI builder'ları, Data Designer ve Business Process Editor’ü kullanarak sonra gerçek isteklerden gelen verilere göre metin ve eylemleri iyileştirebilirsiniz.
Why do generic “403” pages create so many support tickets?Çünkü bu bir çıkmaz gibi hissettirir. Kullanıcılar doğru şekilde oturum açıp açmadıklarını, bağlantının bozuk olup olmadığını veya bir iznin eksik olup olmadığını bilemez; bu yüzden çözmesi için desteğe yazarlar.
What’s the simplest way to make an access-denied screen less frustrating?Bunu ürün akışında gerçek bir adım olarak ele alın, hata dökümü gibi bırakmayın. Ne olduğunu sade bir dille söyleyin, bir sonraki açık eylemi sunun ve destek ekibinin olayı bulması için bir referans kimliği ekleyin.
What’s the difference between unauthenticated and unauthorized, and why does it matter?Kimlik doğrulanmamış (unauthenticated) sistemin sizi henüz tanımadığı—oturum açılmamış ya da oturum süre aşımına uğramış durumudur. Yetkisiz (unauthorized) ise sistemi kim olduğunuzu bildiği ama hesabınızın o alana erişimi olmadığı anlamına gelir. Her durum için farklı sonraki adımlar gerekir.
How do I explain the reason without revealing restricted information?Sadece güvenli olanı doğrulayın: erişimin sınırlı olduğu ve hangi tür bir izin sınırı olduğu (örneğin “bu çalışma alanı” veya “bu alan”) gibi genel terimlerle belirtin. Özel kayıt adları, sayfa başlıkları veya sahipleri asla yazmayın.
What wording is safest for an access-denied message?Varsayılan olarak: “Bu sayfaya erişiminiz yok.” Ardından bir yardımcı satırla erişim isteği veya hesap değiştirme gibi bir sonraki adımı gösterin; kaynak adını veya sayfanın var olup olmadığını belirtmeyin.
When should I show a “Request access” button versus “Contact admin”?Kullanıcı oturum açmışsa ve gerçekçi bir onay yolu varsa “Request access” gösterin. Onay yolu yoksa, yine de bağlam toplayacak şekilde “Contact admin” gibi bir geri dönüş sunun.
What should a request-access form ask for (and what should it avoid)?Kısa tutun ve büyük ölçüde otomatikleştirin. Kim olduğunu (auto-fill), erişmeye çalıştığı genel alanı, eylem türünü ve zaman damgasını yakalayın; onaylayıcıların işine yarayacak kısa bir notu isteğe bağlı bırakın. Destek tarzı uzun formlar sormayın.
How do I prevent users from requesting access and still ending up stuck?Gönderimden sonra hemen onay ve görünür bir durum gösterin; kullanıcı ne olduğunu anlayamazsa tekrar gönderir veya destek açar. "İstek gönderildi" ve bir durum (pending, approved, denied) görmek tekrar bilet açmayı önler.
How do I handle users who are signed in to the wrong account or workspace?Geçerli hesabı gösterin ve belirgin bir “Switch account” veya “Switch organization” seçeneği koyun. Birçok erişim sorunu yanlış çalışma alanında veya yanlış hesapla oturum açılmasından kaynaklanır.
How can I implement these patterns consistently across an internal tool or portal?Tek bir yeniden kullanılabilir erişim-engellendi ekranı bileşeni oluşturun ve bunu basit bir istek/onay iş akışıyla eşleştirin. AppMaster içinde UI builder’larda ekranı oluşturup Business Process ile istekleri yönlendirerek tutarlı bir deneyim sağlayabilirsiniz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
