İlk ekranda ürünün ne yaptığını anlatın
Kurumsal web sitesi yapısı, fintech ürününde şirketi ve hizmeti tanımak için başlangıç sağlar. İlk ekranda hedef kitle, kullanım senaryosu ve somut fayda birlikte anlaşılmalıdır. “Finansın geleceği” gibi geniş bir sloganın yanında ürünün para transferi, işletme ödeme yönetimi veya başka hangi sorunu çözdüğünü açıklayın.
Kısa demo veya ürün görüntüsü, gerçek akışı gösterebilir; örnek verileri gerçek müşteri bakiyesi gibi sunmayın. Kullanıcının bu aşamada fiyat, yetki kapsamı, destek veya ürün detayına erişebilmesi gerekir. Ana eylemi bağlama göre seçin: ürünü incelemek, işletme demosu istemek ve hesap açmak aynı karar değildir.
İlk izlenimin rolünü, her ziyaretçinin önce güven sonra özellik aradığı kesin bir hiyerarşiye dönüştürmeyin. Görüşmelerde kullanıcıya hizmeti, maliyeti ve bir sonraki adımı kendi sözleriyle anlattırın. Yanlış anlaşılan vaadi dekoratif güven rozetleriyle kapatmak yerine metin ve akışı düzeltin.
Şirketi, yetki kapsamını ve riskleri doğrulanabilir gösterin
Hakkımızda sayfasında hizmeti sunan tüzel kişiyi, iletişim kanallarını ve varsa üründeki diğer kuruluşların rolünü açıklayın. Fintech bir ürün kategorisidir; bütün girişimler aynı lisansa tabi değildir. Türkiye’de ödeme ve elektronik para kuruluşları için TCMB’nin güncel kuruluş ve faaliyet kapsamı bilgileri ilgili bir doğrulama kaynağıdır.
Yetki veya lisans ifadesini kuruluş unvanı, kapsam ve resmî kayıt bağlantısıyla ilişkilendirin. Başvuru aşaması, alınmış izin gibi gösterilmemelidir. Bir kurum logosu, devlet garantisi, mevduat güvencesi veya bütün ürünlerin onaylandığı sonucunu kendiliğinden doğurmaz; logonun kullanım koşullarını da kontrol edin.
Ürüne ilişkin kayıp ihtimali, işlem sınırı, para çekme koşulu veya hizmet kapsamı gibi karar için önemli bilgileri ilgili ürün alanında gösterin. Sadece uzun bir alt bilgi metnine saklamayın. Hangi açıklamaların gerektiği, ürünün hukuki niteliğine ve faaliyet ülkesine göre uyum ekibiyle belirlenmelidir.
OKUMADAN SONRAKİ ADIMA
Fintech web akışını birlikte inceleyelim
Ürün mesajlarını, doğrulanabilir güven bilgilerini ve kullanıcı akışını aynı tasarım kapsamına alın.
Politikaları veri toplama bağlamında yapılandırın
Web uygulaması geliştirme planında yasal sayfaların adresini belirlemek yeterli değildir; hangi bilginin hangi adımda gösterileceğini tasarlayın. Kullanıcı sözleşmesi, gizlilik politikası, faaliyete uygun aydınlatmalar ve çerez açıklamaları kolay bulunmalı, sürüm veya güncelleme bilgisiyle yönetilmelidir. GDPR uygulanıyorsa ilgili gereklilikler ayrıca değerlendirilir.
KVKK’nın resmî açıklaması; veri sorumlusu, işleme amacı, aktarım, toplama yöntemi ve hukuki sebep ile ilgili hakları kapsar. Kurumun duyurusu, genel gizlilik politikasının işlem özelindeki aydınlatmanın yerine kullanılmamasını belirtir. Kısa özetler temel bilgiyi sunmalı ve ayrıntılı metne erişim sağlamalıdır; zorunlu içeriği birkaç rahatlatıcı cümleyle değiştirmeyin.
| Bağlam | Kullanıcının sorusu | Tasarım kararı |
|---|---|---|
| Demo formu | İletişim verimi kim, ne için kullanacak? | Faaliyete uygun aydınlatmayı veri toplarken sunun; gereksiz kimlik belgesi istemeyin. |
| Kimlik doğrulama | Bu belge neden gerekiyor ve nasıl iletilecek? | Ürüne uygun gerekçeyi, güvenli yükleme yolunu ve başarısızlık halinde desteği açıklayın. |
| Çerez tercihi | Hangi amaç için hangi tercih yapılabiliyor? | Gerçek çerez ve araç envanteriyle uyumlu açıklama ve tercih akışı kurun. |
| Hak ve destek başvurusu | Kime ulaşacağım, neyi takip edebilirim? | Uygun başvuru yolunu erişilebilir tutun; işleyen ekibe ve sürece bağlayın. |
Güvenlik iddialarının kapsamını açıkça belirtin
HTTPS ve sertifika düzeni, bağlantının korunması için temel bir teknik konudur. Ancak HTTPS, şirketin güvenilirliğini, ürünün risksizliğini veya bütün sistemin güvenli olduğunu kanıtlamaz. Aktarım sırasında şifreleme, saklanan verinin korunması ve uçtan uca şifreleme farklı kavramlardır; yalnızca gerçekten uygulanan yaklaşımı anlatın.
Güvenlik sayfasında erişim kontrolü, veri işleme ve desteklenen giriş yöntemleri gibi kullanıcı açısından anlamlı konuları sade bir şemayla açıklayabilirsiniz. Altyapı sağlayıcısının logosu, girişimin bağımsız denetimden geçtiği anlamına gelmez. ISO sertifikası veya denetim için kuruluş, kapsam ve geçerlilik bilgisi doğrulanmış olmalıdır.
PCI DSS ifadesini kart verisinin işlendiği kapsamla ilişkilendirin. PCI SSC, işlemi dış sağlayıcıya veren işletmelerin de ilgili sorumluluklarının bulunabileceğini açıklıyor. Sağlayıcının uyumunu bütün ürünün otomatik uyumu gibi sunmayın. “Veriler yalnızca hizmeti iyileştirmek için kullanılır” ifadesi de gerçek bütün işleme amaçlarıyla örtüşmedikçe uygun değildir.
Kayıt ve işlem akışında maliyeti ve sonraki adımı açıklayın
Ürün tasarım ve geliştirme sürecinde kayıt, kimlik doğrulama, ücret inceleme ve işlem sonucunu tek bir akış olarak ele alın. AML ve KYC süreçleri, her form alanına otomatik “yasal zorunluluk” etiketi yapıştırmak için gerekçe değildir. Uygulanacak yükümlülük ve belge gereksinimi gerçek ürün için doğrulanmalıdır.
Komisyon, kur farkı, dönemsel ücret, alt sınır veya ek koşullar varsa işlemi etkileyen bilgiler karar öncesinde anlaşılmalıdır. Fiyat tablosunu sadeleştirmek önemli ayrıntıları silmek anlamına gelmez. “Gizli ücret yok” mesajını ancak toplam maliyet ve koşullar gerçekten açık olduğunda kullanın.
Başlamadan önce
Gerekli adımları ve belgeleri açıklayın. Süre tahminini gerçek operasyon verisine dayandırın; demo formunda hesap açılışı için gereken hassas bilgileri toplamayın.
Bilgi girilirken
Alanların neden gerekli olduğunu anlatın. Hata mesajında düzeltilecek alanı belirtin; zaman aşımı veya başarısız yükleme sonrasında güvenli devam yolunu gösterin.
İşlem tamamlanırken
Tutar, alıcı ve maliyeti gözden geçirme fırsatı verin. Alındı, incelemede, tamamlandı ve başarısız durumlarını ayırın; bekleyen işlemi anında başarılı gösteren mesaj kullanmayın.
CTA çevresinde gerçek destek ve koşulları gösterin
Kullanılabilirlik incelemesi, demo veya kayıt butonunun çevresindeki belirsizlikleri ortaya çıkarabilir. Buton ne olacağını söylemeli; yardımcı metin talebin ne başlattığını, hangi bilginin istendiğini ve nasıl destek alınacağını açıklamalıdır. “Ücretsiz”, “anında” veya “7/24” gibi ifadeleri gerçek koşullarla sınırlandırın.
Destek kanalını görünür kılmakla yanıt süresi vaat etmek farklıdır. Canlı destek yalnızca belirli saatlerde çalışıyorsa bunu belirtin. Başvurunun alınması hesabın açılması anlamına gelmiyorsa kullanıcıya inceleme adımını anlatın. İlerleme göstergeleri de belirsiz sayıda adım veya bilinmeyen süreyi kesin bir sonuca dönüştürmemelidir.
Sosyal kanıtı kaynağı ve dönemiyle sunun
Kurumsal referans alanında müşteri logoları, vaka çalışmaları, basın bağlantıları ve kullanım sayıları farklı kanıt türleridir. Logo için ilişkinin niteliği ve kullanım izni; vaka için sorun, uygulama, dönem ve veri kaynağı; medya görünümü için yayının gerçek bağlamı bilinmelidir.
Aktif kullanıcı, kayıtlı hesap ve işlem hacmi birbirinin yerine kullanılmamalıdır. Sayaç gösteriyorsanız tanımı, kapsanan dönemi ve yenilenme yöntemini açıklayın. Uygulama mağazası puanını mağaza ve tarih bağlamıyla sunun. Ödenmiş getiri veya geçmiş performans, gelecekteki kazanç garantisi değildir; ürünün gerektirdiği risk açıklamalarıyla birlikte değerlendirilmelidir.
Basında görünmek veya tanınmış bir müşteriye hizmet vermek bütün kullanıcılar için aynı sonuçları ispatlamaz. Doğrulanmamış sayaç, anonim yıldız veya uydurulmuş müşteri yorumu eklemek yerine henüz hangi kanıtın bulunmadığını kabul ederek ürünün gerçek çalışma biçimini gösterin.
Mobil deneyim ve erişilebilirliği yayın öncesinde sınayın
Mobil kullanılabilirlik testi, yavaş bağlantı, küçük ekran ve yardımcı teknoloji koşullarını da içermelidir. Metin ve alan adları okunabilir, klavye odağı görünür, hatalar anlaşılır olmalıdır. Erişilebilir giriş için parola yöneticisi ve yapıştırma desteğini gereksiz yere engellemeyin; biyometrik yöntemleri bütün kullanıcılar için zorunlu çözüm saymayın.
WCAG 2.2, finansal veya hukuki sonuç doğuran işlemlerde geri alma, hata kontrolü ya da gözden geçirme ve düzeltme mekanizmalarını ele alır. Uygun yaklaşımı ürünün gerçek akışında değerlendirin. Hızlı açılan bir sayfa işlem güvenliğini tek başına kanıtlamaz; erişilebilirlik de sadece renk kontrastından oluşmaz.
Yayın öncesi
Ürün, uyum, güvenlik ve tasarım ekipleri mesajları birlikte incelemeli. Yetki bağlantısı, ücret koşulları, veri açıklamaları, hata senaryoları ve destek kanalları gerçek içerikle doğrulanmalı.
Yayın sonrası
Kayıt adımlarının tamamlanması, hata türleri, destek soruları ve anlaşılmayan mesajlar izlenmeli. Dönüşüm artışı iddiası ölçümle desteklenmeli; hassas bilgiler analitik olaylara taşınmamalı.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Fintech sitesinde güven nasıl gösterilir?
Şirket, ürün, yetki kapsamı, maliyet, veri kullanımı ve destek yolu doğrulanabilir biçimde açıklanır. Tasarım riski ortadan kaldırmaz; kullanıcının kararı anlayabilmesini destekler.
Lisans bilgisi nerede bulunmalı?
Şirket veya uyum sayfasında ayrıntılı ve resmî kayda bağlı olmalıdır. Ürün ya da kayıt kararını etkileyen kapsam bilgisi ilgili adımda da gösterilmelidir; kurum logosu garanti olarak kullanılmamalıdır.
Hangi yasal sayfalar gereklidir?
Gereksinim ürün, kuruluş ve faaliyet ülkesine bağlıdır. Sözleşmeler, veri toplama faaliyetine uygun aydınlatmalar, gizlilik ve çerez alanları gerçek işleyişle eşleşmelidir; genel bir şablon uyum kanıtı değildir.
HTTPS güvenli bir fintech ürünü olduğunu kanıtlar mı?
Hayır. HTTPS bağlantıyı korur. İşletme güvenilirliği, işlem riski, veri saklama güvenliği ve sertifikasyon kapsamı ayrı konulardır; birbirinin yerine sunulmamalıdır.
Müşteri logoları ve işlem sayıları nasıl kullanılmalı?
İzin, ilişkinin kapsamı, veri tanımı ve dönem belirtilmelidir. Kayıtlı hesap ile aktif kullanıcı ayrılmalı; geçmiş hacim veya getiriler gelecek sonuçların garantisi gibi gösterilmemelidir.
Kayıt formunda güven mesajı yeterli mi?
Hayır. Gerekli veri ve gerekçe, gerçek ücretler, hatayı düzeltme, işlem durumu ve ulaşılabilir destek birlikte tasarlanmalıdır. Rahatlatıcı bir cümle belirsiz ürün akışını çözmez.
KAPSAMI BİRLİKTE BELİRLEYELİM
Fintech web akışını birlikte inceleyelim
Ürün mesajlarını, doğrulanabilir güven bilgilerini ve kullanıcı akışını aynı tasarım kapsamına alın.
Web projesini görüşelim