Don Norman'ın UX ilkeleri, kafa karıştıran akışları tespit etmenize, destek maliyetlerini azaltmanıza ve kullanıcılar takılmadan önce sohbetle oluşturulan ekranları doğrulamanıza yardımcı olur.
Kafa karıştıran arayüzler sadece kötü hissettirmekle kalmaz. Ölçülebilir maliyetler yaratırlar: insanlar kayıt ve ödeme işlemlerini bırakır, iade ister, ve açık olması gereken şeyler için desteğe başvurur.
Çoğu zaman sorun görsel tasım değildir. Sorun açıklıktır. Kullanıcılar sistemin ne istediğini, bir sonraki adımda ne olacağını ya da ilerlemenin güvenli olup olmadığını anlayamaz.
Bu kafa karışıklığı birkaç öngörülebilir şekilde gerçek para ve zamana dönüşür. İnsanlar şüphe anına gelince işlemi bırakır. Destek “X nerede?” ve “Neden böyle oldu?” mesajlarıyla dolar. Fiyatlandırma, onay veya iptal akışları belirsizse iadeler ve chargeback’ler artar. İçeride takımlar, ürün kendini açıklamadığı için rehberler ve geçici çözümler yazmakla vakit harcar.
Küçük sürtünmeler pahalı olur çünkü sık kullanılan akışlarda tekrarlanır. Kafa karıştıran bir kayıt bir kerelik bir kullanıcı kaybına mal olabilir. Kafa karıştıran bir ödeme sayfası ise her seferinde maliyete neden olabilir.
Basit bir senaryo nasıl olduğunu gösterir: biri bir hesap yaratır ve bildirim sıklığı gibi bir ayarı değiştirir. Bir anahtar görür, dokunur ve hiçbir şey değiştiğini onaylamaz. Sonra hala e-postalar gelmeye devam eder. Şimdi bir destek bileti, kullanıcı kendini kandırılmış hisseder ve güven düşer. UI temiz görünebilir, ama deneyim net değildir.
Hız bunu gözden kaçırmayı kolaylaştırır. Özellikle ekranları ve akışları hızlı üreten sohbet araçlarıyla hızlı kurduğunuzda, adımlar kurucusuna mantıklı gelir ama ilk kez kullanan birine mantıklı gelmeyebilir.
Çözüm, Don Norman ile sıklıkla ilişkilendirilen bazı fikirlerle başlar: eylemleri görünür kılın, kullanıcının zihinsel modeliyle eşleştirin, hızlı geri bildirim verin ve hataları olmadan önce önleyin. Bu rehberin geri kalanı pratik kalıyor: birkaç ilke ve sohbetle hızlı oluşturduğunuz herhangi bir akışı gerçek kullanıcılar kaybolmadan önce doğrulamak için basit bir rutin.
İnsanlar arayüzleri okumaz. Tahminde bulunur.
Kullanıcılar, başka uygulamalar, gerçek dünya nesneleri ve alışkanlıklara dayanan nasıl çalışması gerektiğine dair bir zihinsel modele sahiptir. Arayüzünüz o modelle eşleştiğinde insanlar hızlı hareket eder. Modelle çatıştığında yavaşlar, tereddüt eder ve aslında tasarım hatası olan “hatalar” yaparlar.
Bir kullanıcı “Kaydet”e tıkladığında işinin güvenli olduğunu bekler. “Sil”e tıkladığında bir uyarı veya kolay geri dönüş bekler. Bir arama kutusu gören bir kullanıcı yazıp Enter’a basabileceğini bekler. Bu beklentiler herhangi bir yardım metninden önce vardır.
İyi UX, insanları yeniden eğitmeye çalışmak yerine bu beklentilere dayanır.
Bir affordance bir öğenin ne yapabileceğidir. Bir signifier ise bunun yapılabildiğini gösterendir.
Bir metin alanı yazılabilmeyi afford eder. Signifier gözüken kutu, imleç ve bazen placeholder metnidir. Bir düğme tıklanmayı afford eder. Signifier şekli, kontrastı ve etikettir. Bir düğmeyi düz metin gibi stillendirirseniz affordance değişmez, ama signifier zayıflar ve insanlar onu kaçırır.
Execution uçurumu, kullanıcının istediği ile UI’nin sunduğu eylemler arasındaki farktır. Birisi gönderim adresini değiştirmek istiyorsa ama sadece “Profili Düzenle” görürse ne yapacağını bilmeyebilir.
Evaluation uçurumu ise sistemin ne yaptığını ve kullanıcının ekrandan ne anlayabildiği arasındaki farktır. “Öde”ye tıklar ve hiçbir şey değişmezse (ya da sadece küçük bir spinner görünürse) bunun çalışıp çalışmadığını, başarısız olup olmadığını veya halen işlemde olup olmadığını anlayamazlar.
İyi geri bildirim hızlı, net ve spesifiktir. Üç soruyu cevaplar: işe yaradı mı, ne değişti ve sırada ne yapmalıyım?
Bu, sohbet tabanlı araçlarla hızlı üretilen ekranlarda daha da önemlidir. Üretilmiş ekranlar hâlâ belirgin signifier’lar ve şaşmaz geri bildirimler gerektirir, böylece ilk kez kullananlar kaybolmaz.
Kafa karıştıran arayüzler nadiren kod yanlış olduğu için başarısız olur. Başarısız olmalarının nedeni ekranın insanların bir sonraki adımda ne olacağını düşündüğüyle eşleşmemesidir.
Klasik örnek “Kaydet vs Gönder vs Yayınla” karışıklığıdır. Birçok araçta “Kaydet” taslağı kaydetmek, paylaşmak ya da süreci bitirmek anlamına gelebilir. Sadece çalışmasını güvence altına almak isteyen bir kullanıcı tereddüt eder veya yanlış tıklar ve paniğe kapılır. “Taslağı Kaydet” ve “Şimdi Yayınla” gibi etiketler bu korkuyu azaltır çünkü sonucu açıklar.
Ayar ekranları da sessiz hasara neden olur. Anlaşılmaz veya ters çevrilmiş anahtarlar her yerde: “Bildirimler” yazılı bir anahtar ON’ın ne anlama geldiğini söylemiyor. Daha kötüsü, başka bir bağımlılık nedeniyle görünüşte açık olan bir anahtarın aslında kapalı olmasıdır. İnsanlar sayfaya güvenmeyi bırakır ve tahmin etmeye başlar.
Formlar sık sık tekrar eden sorun kaynaklarıdır. Hata nedeni açıklanmadan başarısız olan bir kayıt formu temelde kullanıcılara “Şansını dene” demektir. Şifre kuralları hata sonrası saklanıyorsa, zorunlu alanlar sadece küçük bir kırmızı kenarlıkla gösteriliyorsa veya “Geçersiz giriş” gibi mesajlar ek iş yükü yaratır.
Boş durumlar da insanları tuzağa düşürebilir. Sadece “Henüz veri yok” diyen boş bir pano kullanıcıyı yalnız bırakır. Yararlı bir boş durum bir soruyu yanıtlar: sırada ne yapmalıyım? Basit bir “İlk projenizi oluşturun” ve sonrasında ne olacağına dair bir cümle genellikle yeterlidir.
Yıkıcı eylemler masum görünen ifadelerin arkasına saklanabilir. “Kaldır” bir listeden çıkarmak veya kalıcı silmek anlamına gelebilir. Sonuç geri alınamazsa, ifade bunu belirtmelidir.
Hızla inşa ediyorsanız, öncelikle kontrol etmeniz gereken alanlar şunlardır: buton etiketleri sonucu tanımlamalı, anahtarlar ON ve OFF’ın ne anlama geldiğini belirtmeli, form hataları tam alanı ve kuralı göstermeli, boş durumlar bir sonraki adımı sunmalı ve yıkıcı eylemler açıkça isimlendirilmeli ve gerekirse onay istemelidir.
Çoğu kafa karışıklığı ürünün ekranlardan dışa doğru inşa edilmesinden değil, kullanıcı hedefinden içeri doğru inşa edilmemesinden başlar. Bir ekran tamamlanmış görünebilir ama birinin geldiği işi bitirmesine yardımcı olmuyorsa başarısız olur.
Bir hedef seçin ve onu bir özellik değil bir görev gibi yazın: “Fatura oluştur ve gönder”, “Cuma için saç kesimi randevusu al”, veya “Bir açılış sayfası yayınla.” Bu hedef sizin çapanızdır çünkü “bitti”nin ne demek olduğunu tanımlar.
Sonra yolculuğu en küçük doğal adım setine yakınlaştırın. Kafa karışıklığını azaltmanın en hızlı yollarından biri, kurucunun ekstra bağlam bildiği için var olan adımları çıkarmaktır. Kurucular genellikle ön ayarları başta koyar çünkü kurulum sırasında mantıklıydı. Yeni kullanıcılar genellikle önce işi yapmak, sonra ayarları değiştirmek ister.
Pratik bir test her adımı üç soruyla kontrol etmektir:
Herhangi bir adım bu sorulardan birinde başarısızsa kullanıcılar yavaşlar. Üzerinde gezinirler, kaydırır, rastgele menüler açar veya bir iş arkadaşına sormak için ayrılırlar.
Tahmin edilebilir duraklama noktalarını arayın: farkları belirsiz bir seçim (“Workspace” vs “Project”), ellerinde olmayan bilgi isteyen bir form, bir sayfada birden fazla birincil düğme veya akış sırasında terminolojinin değişmesi (kayıt, sonra “provision”, sonra “deploy”).
Bir duraklama noktası gördüğünüzde bir sonraki eylemi hedefle hizalayın. Kullanıcının kelimelerini kullanın, gelişmiş ayarları sonraya taşıyın ve bir tane belirgin sonraki adım yapın. Akış rehberli bir yol gibi hissettirmeli, soru gibi değil.
İnsanlar sistemin ne yaptığını ve bir işlemden sonra ne olduğunu bilirlerse neredeyse her arayüzü kullanabilir. Kafa karışıklığı ekran sessiz kaldığında başlar: kaydedildiğine dair işaret yok, işlemin sürdüğüne dair gösterge yok, düğmenin herhangi bir şey yapıp yapmadığına dair kanıt yok.
Hızlı geri bildirim süs değildir. Arayüzün “Seni duydum” demesidir. Bu, çift tıklamaları, öfkeyle sayfayı yenilemeyi ve terk edilen formları önler.
Bir işlem bir kırpmadan uzun sürüyorsa görünür bir durum gösterilmelidir. Bu, sayfa yükleme, ödeme işleme, dosya yükleme, rapor oluşturma veya mesaj gönderme gibi durumları kapsar.
Basit bir kural: kullanıcı “Çalıştı mı?” diye sorabiliyorsa UI zaten cevaplıyor olmalıdır.
Somut tutun:
Bir onay, ne değiştiğini ve nerede bulunacağını söylediğinde yararlıdır. “Başarılı” belirsizdir. “Fatura [email protected] adresine gönderildi. Gönderilen faturalar bölümünde görebilirsiniz” gibi spesifik ifadeler sakinleştirir.
Hatalar rehber olmalı, cezalandırıcı değil. İyi hata geri bildirimi üç parçaya sahiptir: ne yanlış gitti, nasıl düzeltilir ve kullanıcının çalışmasını kaybetmediğine dair güvence. Yazdıklarını koruyun. Bir alan yanlış diye bir formu sıfırlamayın.
Sessiz hatalar en kötüsüdür. Bir şey başarısız olursa bunu açıkça söyleyin ve sonraki eylemi sunun (Tekrar dene, Düzenle, Destek ile iletişime geç). Otomatik kaydetme varsa gösterin. Kaydedemiyorsanız nedenini söyleyin.
İnsanlar genellikle dikkatsiz oldukları için hata yapmazlar. Yanlış hareket etmelerine izin veren veya bir sonraki adımın ne olacağını göstermeyen arayüzler hata yapmalarına neden olur.
Don Norman’ın sınıtlama fikri basittir: en güvenli eylemi en kolay eylem yapın.
İyi bir sınıtlama çıkmaz yol değildir. Bir şey devre dışıysa kullanıcılar nedenini ve nasıl düzelteceklerini anlamalıdır. “Kaydet” gri ve açıklamasızsa bozuk hisseder. “Kaydet (devam etmek için başlık ekleyin)” yardımcı olur.
Birkaç desen, insanları denetlemeden kafa karışıklığını azaltır. Serbest metin yerine yanlış yazımları önleyecek seçiciler veya ön ayarlar kullanın (tarihler, ülkeler, roller). En yaygın duruma uygun mantıklı varsayılanlar verin, sonra ileri seviye kullanıcıların değiştirmesine izin verin. Yazarken doğrulama yapın ve spesifik mesajlar gösterin. Bir işlemi devre dışı bıraktığınızda nedenini hemen yanında gösterin.
Somut örnek: hızlı oluşturulmuş bir “Workspace oluştur” akışı düşünün. Veri tabanı bölgesi gerekli ise kullanıcılardan yazmalarını istemeyin. Önerilen varsayılanı olan bir seçici sunun ve neden önemli olduğuna dair kısa bir not ekleyin. İsim gerekliyse kuralı baştan gösterin (“3 ile 30 karakter”) final adımda bekletmek yerine.
Onay diyalogları korkutucu olmamalıdır. Spesifik olmalıdır. “Emin misiniz?” yerine neyin silineceğini, nelerin kaybolacağını ve geri alınıp alınamayacağını söyleyin.
Güvenli bir çıkış hata önlemenin parçasıdır. “İptal” ve “Geri” ilerlemeyi sessizce silmemelidir. Mümkünse ekipten birini kaldırmak veya taslağı silmek gibi işlemler için Geri Al sunun.
Hatanın maliyeti yüksekse ekstra sürtünme değerdedir: ödemeler, plan yükseltmeleri, veri veya hesap silme, izin verme, gerçek müşterilere davet gönderme veya geri alınmaz dışa aktarma ve sıfırlamalar. Amaç insanları yavaşlatmak değil, tıklamadan önce sonuçları görünür kılmaktır.
Bir özelliği sohbet tabanlı bir oluşturucuyla hızlı kurduğunuzda risk kötü kod değil. Risk, kurucusuna mantıklı gelen ama ilk kez kullanan birine mantıklı gelmeyen bir akıştır. Gerisi karışıklık vergisi ödemeden önce bu kısa doğrulama döngüsünü kullanın.
Kısa döngüler, tek seferlik uzun incelemeleri yener.
Hız iyidir ta ki nelere dikkat ettiğinizi değiştirmeye başlayana kadar. Sohbet araçları tutarlı detaylarla doldurabilir. Kullanıcılar doldurmaz. Kendi kelimelerini, hedeflerini ve sabrını getirirler.
Yaygın bir başarısızlık kelime dağılmasıdır. Kurucular ve sohbet istemleri iç terminlerde kayar: “workspace”, “entity”, “billing profile” veya “sync”. Yeni bir kullanıcı sadece “bir ekip üyesi eklemek” veya “bir fatura göndermek” ister. Etiketler kullanıcının zihinsel modeliyle eşleşmiyorsa insanlar yavaşlar ve vazgeçer.
Bir diğer tuzak arayüzü veri tabanını aynen yansıtmak. first_name, status_id, plan_tier gibi alanları göstermek kolaydır ama insanlar tablo sütunlarında düşünmez. Onlar sorular ve eylemler düşünür: “Bu kimin için?”, “Sonraki ne olacak?”, “Bunu geri alabilir miyim?”
Hızlı oluşturma ayrıca özellik yığılmasını davet eder. Bir adım garip hissettirdiğinde içgüdü eklemek olur: bir seçenek, sekme veya gelişmiş bölüm. Bu genellikle gerçek sorunu gizler: ilk kafa karıştırıcı an hâlâ kafa karıştırıcılığını korur.
Yardımcı metni dayanacak bir destek olarak kullanmaya dikkat edin. Placeholder’lar ve minik ipuçları kendini açıklamayan bir düzeni kurtaramaz. Ekranın paragraf paragraf açıklama istemesi, tasarımın kullanıcıya okumayı değil eylemi dayattığını gösterir.
Ayrıca “temiz” olmak maliyetli olabilir. Ana eylemi bir menüye gizlemek düzenli görünebilir ama insanların aramasına neden olur. Bir ekranda tek bir ana eylem varsa, o ana eylem gibi görünmelidir.
Son olarak hız kenar durumları gizler. Mükemmel veriyle çalışan bir akış gerçek hayatta hızlıca başarısız olabilir: boş durumlar, yavaş ağlar, yanlış girişler veya kullanıcı adım ortasında geri çekilmesi.
Kafa karıştıran bir akış sessizce destek bileti, iadeler ve terk eden kayıtlar ekler. Hızla oluşturduğunuz bir ekranı veya akışı göndermeden önce aynı üç fikri kullanarak 10 dakikalık bir kontrol yapın: net signifier’lar, anında geri bildirim ve nazik sınıtlamalar.
Ana yolla başlayın (kullanıcıların çoğunun geldiği şey) ve kontrol edin:
İnsanların atladığı bir kontrol: başarı ve hata sonrasında sonraki adım açık olmalı. Başarı durumu bir sonraki faydalı eyleme işaret etmeli (Makbuzu gör, Siparişi takip et, Ekip davet et). Hata durumu kullanıcıyı kontrolü elinde tutarak bırakmalı (Bu alanı düzelt, Tekrar dene, Destek ile iletişime geç) ve girdileri silmemeli.
Eğer Koder.ai üzerinde inşa ediyorsanız, bu kontrol listesini dağıtmadan önce UI kopyası ve durumları için son bir geçiş olarak kullanın. Planning Mode, bir cümlelik hedefi ve beklenen adımları baştan yazmanıza yardımcı olabilir, böylece üretilmiş UI bitmiş görünür ama labirent gibi davranmaz.
Hız hedef değildir. Açıklık hedeftir. En hızlı yapı, insanların geldikleri tek şeyi bitiremiyorsa yine bir başarısızlıktır.
Sizi dürüst tutacak basit bir alışkanlık: her sürümde bir temel akışı gözden geçirin. Faturayı ödeyen veya güven oluşturan (kayıt, oluşturma, ödeme, davet) akışı seçin. O akış net olduğunda diğer her şey daha kolay hissedilir.
Değişiklikleri küçük ve görünür yapın. Buton etiketini, hata mesajını ve sayfa düzenini aynı anda değiştirirseniz neyin yardımcı olduğunu bilemezsiniz.
Gerçek kullanıcı testi bir laboratuvara ihtiyaç duymaz. Birine basit bir görev verin ve sessiz kalın. Tereddüt ederse, o sizin hata raporunuzdur.
Hızla kurup yineleyen takımlar için Koder.ai gibi araçlar prototip ve dağıtımda yardımcı olabilir, ama UX’in temel kuralları kullanıcıların işi bitirip bitirmeyeceğini belirler. Açıklık çalışmasını bir temizlik adımı değil, inşa sürecinin parçası olarak görün.
Kafa karıştıran arayüz, tekrarlanabilir maliyetler yaratır:
Her adımda bir ilk kez kullanıcı üç soruyu cevaplayabiliyorsa açıklık vardır:
Arayüz görsel olarak “temiz” olsa bile sonuçları öngörülebilir kılmıyorsa başarısız olur.
Bir mental model, kullanıcının başka uygulamalar ve günlük alışkanlıklardan edindiği, bir şeyin nasıl çalışması gerektiğine dair beklentisidir.
Varsayılan yaklaşım: yaygın beklentilerle eşleştirin (ör. “Kaydet” çalışmayı güvende tutar; “Sil” uyarır veya geri alınabilir). Beklentiyi kırmanız gerekiyorsa, bunu açık etiketler ve geri bildirim ile yapın ki kullanıcı tahmin etmek zorunda kalmasın.
Bir affordanser (affordance) bir şeyin ne yapabileceğidir. Bir signifier ise o eylemin açıkça görülmesini sağlar.
Örnek: bir düğme düz metin gibi görünse bile hâlâ tıklanabilir, ama signifier zayıftır; insanlar onu fark etmez. Pratik düzeltme: net etiketler, kontrast, yerleşim ve durum değişiklikleri (basılı/yükleniyor/devre dışı) ile signifier’ı güçlendirin.
Hızlı bir teşhis için kullanın:
Her ikisini kapatmak için: sonraki eylemi kolay bulunur yapın ve sonuçları kesin şekilde gösterin.
Sonuç odaklı etiketler kullanın.
Amaç: kullanıcı tıklamadan önce sonucu bilsin.
Açık ON/OFF anlamı verin ve sistemi doğru gösterin:
Özellikle görünürken aslında kapalı olan düğmelerden kaçının.
Varsayılan kural: birisi “Çalıştı mı?” diye sorabiliyorsa, UI zaten cevaplamalıdır.
Pratik kalıplar:
Güvenli yolu en kolay yol yaparak hataları önleyin:
Yıkıcı işlemler için ne silineceğini, nelerin kaybolacağını ve geri alınıp alınamayacağını belirterek onay isteyin.
Hızla inşa edilip gönderilmeden önce kısa bir doğrulama döngüsü çalıştırın:
Koder.ai kullanıyorsanız, Planning Mode ile amaç ve beklenen adımları önceden yazın, sonra dağıtmadan önce bu geçişi yapın.
