UX araştırması ve prototipleme: iyi bir arayüz nasıl tasarlanır?

Sitenizdeki teklif formu çalışıyor, talepler geliyor. Ama satış ekibi neredeyse her talepte müşteriyi geri arayıp aynı soruları soruyor: hangi debi, hangi basınç, hangi akışkan, kaç adet? Bir kısım ziyaretçi formu yarıda bırakıp telefon açıyor; mesai dışında gelen ise hiç dönmüyor. Tasarımcıya “formu biraz güzelleştirelim” demek cazip, ama sorunun güzellikle ilgisi yok.

Bu yazıda iyi bir arayüzün nasıl tasarlandığını tek bir senaryo üzerinden anlatıyoruz: Bursa'da endüstriyel pompa üreten, bayilere ve proje firmalarına satış yapan orta ölçekli bir şirketin teklif formu. Araştırmadan prototipe, kullanıcı testinden geliştiriciye devre ve yayından sonraki ölçüme kadar her adımda ne yapıldığını ve neyin atlanmaması gerektiğini göreceksiniz. Aynı yöntem bir e-ticaret ödeme adımına da, bir randevu akışına da uygulanır.

Araştırma: tasarımdan önce kimi dinleyeceksiniz?

Araştırma “neyi bilmiyoruz?” sorusuyla başlar. Pompa örneğinde bilinmeyenler belliydi: müşteri teklif isterken elinde hangi bilgiler oluyor, hangilerini bilmiyor, satış ekibi bir teklifi hazırlamak için gerçekte neye ihtiyaç duyuyor? Bunları dört kaynaktan topladık.

Paydaş görüşmeleri

Satış, teknik destek ve üretim planlamadan birer kişiyle birebir, bir saati geçmeyen görüşmeler. Soru basit: bir teklif talebi geldiğinde ne oluyor, iş nerede tıkanıyor? Pompa örneğinde iki şey çıktı. Formdaki alanların bir kısmına kimse bakmıyordu. Teklif için en çok gereken bilgi, yani akışkanın sıcaklığı ve içinde katı madde olup olmadığı, formda hiç sorulmuyordu.

Bu görüşmelerde en çok işe yarayan sorular şunlardı:

• Bir talebin teklife dönüşmesi için hangi bilgiler kesinlikle gerekli?
• Müşteriyi geri aradığınızda en çok neyi soruyorsunuz?
• Hangi talepleri ciddiye almıyorsunuz ve neden?
• Form değişirse sizin günlük işinizde ne değişir?

Kullanıcı görüşmeleri

Sonra gerçek müşterilerle, yani bayilerin satın alma sorumlularıyla ve proje firmalarının mühendisleriyle konuştuk. Beş altı görüşme bile çok şey gösterir. Yönlendirmeyen sorular sorun: “Son teklif talebinizi baştan anlatır mısınız?” işe yarar, “Formumuz kolay mıydı?” yaramaz. İnsanlar ne yaptıklarını anlatırken oldukça dürüsttür; ileride ne isteyeceklerini tahmin ederken değil.

Görüşmeleri kaydedecekseniz katılımcıyı önceden bilgilendirin ve onayını alın. KVKK kapsamındaki aydınlatma yükümlülüğü araştırma görüşmeleri için de geçerlidir.

Analitik verisi

Google Analytics 4'te geliştirilmiş ölçümün form etkileşimleri seçeneği açıksa, form_start ve form_submit olaylarıyla formu kaç kişinin başlatıp kaç kişinin gönderdiğini görebilirsiniz. Bu otomatik olay her form yapısında güvenilir çalışmayabilir; başarılı gönderimi teşekkür ekranına bağlı ayrı bir olayla ölçmek daha sağlamdır. Keşfet bölümündeki dönüşüm hunisi keşfiyle ziyaretçinin forma hangi sayfadan geldiğini ve nerede koptuğunu izlersiniz. Oturum kayıtları ve ısı haritaları (Hotjar ya da Microsoft Clarity gibi) hangi alanda duraksandığını gösterir; bu araçları çerez onayı olmadan çalıştırmayın. Verileri mobil ve masaüstü için ayrı ayrı okuyun; aynı form iki cihazda bambaşka davranabilir.

Rakip ve örnek incelemesi

Rakiplerin teklif formlarına ve sektör dışındaki iyi örneklere bakın; mümkünse bizzat doldurup gönderin ve size nasıl dönüldüğünü de görün. Amaç kopyalamak değil, müşterinin başka yerlerde neye alıştığını görmek. İncelemeyi Nielsen Norman Group'un on kullanılabilirlik ilkesi gibi bir çerçeveyle yapmak, “bence güzel olmuş” yorumlarını azaltır.

Her yöntem başka bir soruyu cevaplar ve hiçbiri tek başına yetmez:

Persona mı, yapılacak iş mi?

Pek çok projede araştırma bir persona posteriyle biter: “Satın alma müdürü Ahmet, 42 yaşında, iki çocuk babası, kahvesini sade içer.” Bu tür demografik ayrıntılar tasarım kararlarına nadiren yardım eder. Ahmet'in yaşı, formda hangi alanın zorunlu olacağını belirlemez.

Alternatif, Clayton Christensen'in adıyla anılan “yapılacak iş” (jobs to be done) yaklaşımıdır. Soru şu: müşteri hangi durumda, hangi sonuca ulaşmak için bu ürünü ya da bu formu “işe alıyor”? Pompa örneğinde iki ayrı iş çıktı:

• Bayi: “Müşterim bekliyor; elimdeki model numarasıyla hızlıca fiyat ve termin öğrenip ona dönmek istiyorum.”
• Proje mühendisi: “Yeni bir tesis için doğru pompayı seçmem gerekiyor; teknik değerleri veriyorum, uygun modeli ve teknik föyü istiyorum.”

Aynı form iki işi de kötü yapıyordu. Bayi on dört alan doldurmak istemiyordu; mühendis ise kendi teknik bilgilerini girecek yer bulamıyordu. Çözümün çekirdeği girişteki tek bir soruydu: “Model numaranız var mı?”

Bu, personaları çöpe atın demek değil. Nielsen Norman Group da iki aracın birbirini tamamlayabileceğini savunur; araştırmaya dayanan, davranışı anlatan personalar ekibin empati kurmasını kolaylaştırır. Bizim tercihimiz şu: B2B formları, ödeme adımları ve araç benzeri arayüzlerde önce işleri yazın, persona gerekiyorsa sonra ekleyin.

Bilgi mimarisi ve kart sıralama

Bilgi mimarisi, içeriğin nasıl gruplanıp adlandırıldığıdır: menüde ne var, hangi sayfa hangisinin altında, kategoriler neye göre ayrılıyor. Pompa üreticisinin sitesinde ürünler şirketin iç mantığına göre, seri adlarıyla dizilmişti. Müşteriler ise uygulama alanına göre arıyordu: atık su, yangın, iklimlendirme, gıda.

Bunu tahminle değil, kart sıralamayla çözersiniz. Açık kart sıralamada katılımcılara içerik kartları verilir, kendi gruplarını oluşturup adlandırmaları istenir. Kapalı kart sıralamada gruplar önceden bellidir ve katılımcı kartları bunlara yerleştirir. Nielsen Norman Group açık kart sıralama için çoğu projede 15 kadar katılımcı önerir; Optimal Workshop gibi araçlarla çalışma çevrim içi yürütülebilir.

Etiketlerde müşterinin kelimelerini kullanın. Görüşmelerde mühendisler “basma yüksekliği” diyordu, sitede ise başka bir teknik terim yazıyordu; aynı şeyden söz ediliyor ama arayan bulamıyor. “Çözümler” ya da “Hizmetlerimiz” gibi her şeyi kapsayan etiketler de ziyaretçiye içeride ne olduğunu söylemez.

Yeni yapıyı doğrulamak için ağaç testi (tree testing) daha uygundur. Katılımcıya yalnızca menü hiyerarşisi metin olarak gösterilir ve “Atık su pompası için teknik föyü nerede bulursunuz?” gibi görevler verilir. Görsel tasarım işin içine girmediği için sonuç doğrudan yapının kendisini ölçer.

Kullanıcı akışları ve tel çerçeve

Kullanıcı akışı, bir kişinin hedefine ulaşmak için geçtiği adımların haritasıdır. Teklif formu için bunu iki iş üzerinden çizdik: model numarası olan bayi ve teknik değerlerle gelen mühendis. Her akışta yalnızca sorunsuz yolu değil istisnaları da çizin: kullanıcı birimi bilmiyorsa, dosya yüklemesi başarısız olursa, form mesai dışında gönderilirse ne olacak?

Tel çerçeve (wireframe), bu akışın gri kutularla kâğıda dökülmüş hâlidir. Renk, fotoğraf ve yazı tipi bilerek dışarıda bırakılır; böylece tartışma “bu mavi mi olsun” yerine “bu alan burada mı olmalı” üzerinde kalır. Tel çerçevede gerçek metin kullanın. Etiketi “Lorem ipsum” olan bir form alanının yardım metni ve hata mesajı da düşünülmemiş demektir.

Akış, form gönderilince bitmez. Başarı ekranı ne diyecek, müşteriye giden onay e-postasında talebin özeti var mı, satış ekibinin ne zaman döneceği yazıyor mu? Mesai dışında gelen talebe “Pazartesi sabah size dönüyoruz” demek, sessiz kalmaktan iyidir.

Pompa örneğinde tel çerçeve aşamasında alınan kararlar şunlardı:

• Girişte iki yol: “Model numaram var” ve “Uygun pompayı birlikte seçelim”.
• Bayi yolunda dört alan: model, adet, istenen teslim tarihi, iletişim bilgileri.
• Mühendis yolunda her adımda tek konu soran, adım adım ilerleyen bir form: uygulama alanı, akışkan, debi ve basınç, ek bilgiler, iletişim.
• Birim seçimi (m³/saat ya da litre/saniye) alanın içinde; kullanıcı hesap makinesine gitmek zorunda kalmıyor.
• Her teknik alanda “Emin değilim” seçeneği. Değer bilinmiyorsa alan boş geçilebiliyor ve satış ekibi bunu talebin içinde görüyor.

Tıklanabilir prototip ve az kullanıcıyla test

Tel çerçeveler onaylandıktan sonra Figma'da tıklanabilir bir prototip hazırlanır. Amaç kodlanmış bir site değil, gerçeğe yeterince yakın bir deneyimdir: butonlar çalışır, adımlar arasında geçilir, hata mesajları görünür. Mobil tasarımı mutlaka telefonda deneyin; Figma'nın mobil uygulaması prototipi gerçek ekranda açmanızı sağlar. Sahadaki bir mühendisin teklifi şantiyede, tek eliyle ve güneş altında isteyebileceğini hesaba katın.

Her ekranı prototiplemeniz gerekmez; testte sınayacağınız görevlerin geçtiği ekranlar yeter. Gri kutulardan oluşan düşük sadakatli bir prototip akış ve yapı sorularını test etmek içindir. Metin, görsel hiyerarşi ve küçük etkileşimler gibi konular ise gerçeğe yakın, yüksek sadakatli bir prototip ister. İkisini aynı anda test etmeye çalışırsanız katılımcı renklere yorum yapar, siz de akışla ilgili cevap alamazsınız.

Kaç kullanıcı yeter?

Jakob Nielsen'in 2000 yılında yayımladığı ve Thomas Landauer ile 1993'te geliştirdikleri modele dayanan öneri hâlâ en pratik başlangıç noktasıdır: kullanılabilirlik sorunlarını bulmak için beş kullanıcıyla test edin, sorunları düzeltin, sonra yeniden test edin. Nielsen'in gerekçesi, her yeni katılımcının öncekilerin gördüğü sorunları büyük ölçüde tekrarlamasıdır. Bütçeyi tek büyük teste değil, birkaç küçük tura bölmek daha çok şey öğretir.

Bu kuralın sınırları da var. Birbirinden çok farklı kullanıcı grupları varsa (bizim örnekte bayi ve mühendis) her gruptan ayrı katılımcı gerekir. Oran ölçmek istiyorsanız, örneğin formu kaç kişinin hatasız tamamladığını bilmek istiyorsanız, çok daha fazla katılımcılı nicel bir çalışma gerekir. Beş kişilik test sorunları bulur; ne sıklıkta yaşandıklarını kanıtlamaz.

Test nasıl yürütülür?

• Gerçek bir görev verin: “Elinizdeki şu teknik değerlerle teklif isteyin.” “Formu bir inceleyin” görev değildir.
• Katılımcıdan aklından geçenleri sesli söylemesini isteyin ve susun. Yardım etmek, ipucu vermek, “şuraya tıklayabilirsiniz” demek testi bozar.
• Takıldığı yeri, kullandığı kelimeleri ve ne beklediğini not alın. Neyi beğendiğini sormak en az işe yarayan sorudur.
• Her oturuma bir gözlemci daha alın, tercihen satış ekibinden. Kendi formunda birinin takıldığını gözüyle gören ekip, rapor okuyan ekipten çok daha hızlı ikna olur.
• Kayıt alacaksanız katılımcıyı bilgilendirin, onayını alın ve kayıtları ne kadar süre saklayacağınızı belirleyin.

Moderatörlü testler, yüz yüze ya da görüntülü görüşmeyle, “şu an ne bekliyordunuz?” diye sormanıza izin verir. Maze gibi araçlarla yapılan moderatörsüz uzaktan testler daha çok kişiye hızlı ulaşır ama takılan kişiye o soruyu soramazsınız. İlk turlar için moderatörlü testi öneriyoruz. Katılımcıları mevcut müşteri ve bayilerden seçin. Şirket içinden iş arkadaşları en kötü katılımcılardır, çünkü ürünü ve jargonu sizin kadar iyi bilirler.

Pompa örneğinde ilk turda mühendisler birim seçiminde takıldı; bayiler ise model numarasının ürün etiketinde nerede yazdığını bilmiyordu. İkinci turda alanın yanına küçük bir etiket görseli eklendi ve o sorun bir daha görülmedi.

Erişilebilirlik tasarım masasında başlar

Erişilebilirliği geliştirme sonunda bir denetim maddesi olarak görmek en pahalı yoldur. Kararların çoğu tasarımda verilir ve orada düzeltmek dakikalar sürer. WCAG 2.2, Ekim 2023'te W3C önerisi olarak yayımlandı ve formlarla doğrudan ilgili yeni ölçütler getirdi:

• Hedef boyutu (2.5.8, AA): tıklanabilir öğeler en az 24×24 CSS pikseli olmalı ya da aralarında yeterli boşluk bulunmalı. Küçük onay kutuları ve yan yana sıkışmış bağlantılar en sık hatadır.
• Odağın gizlenmemesi (2.4.11, AA): klavyeyle odaklanılan alan, yapışkan başlık ya da çerez bandı gibi öğelerin arkasında tamamen kaybolmamalı.
• Tekrarlanan giriş (3.3.7, A): aynı süreçte daha önce girilen bilgi yeniden istenmemeli; otomatik doldurulmalı ya da seçilebilir olmalı. Fatura adresini ve teslimat adresini iki kez yazdırmak bu ölçüte takılır.
• Erişilebilir kimlik doğrulama (3.3.8, AA): giriş adımı, bir alternatif ya da yardımcı yol sunulmadıkça şifre hatırlamak gibi bilişsel bir test gerektirmemeli. Şifre alanına yapıştırmayı ya da parola yöneticilerini engellemek bu yüzden kötü fikirdir.
• Sürükleme hareketleri (2.5.7, AA): sürükleyerek yapılan her işlemin tek dokunuşla yapılabilen bir alternatifi olmalı.

Bunlara eski ama sık çiğnenen kurallar eklenir: normal metinde en az 4,5:1 kontrast, her alan için görünür bir etiket (yer tutucu metin etiket değildir), yalnızca renge dayanmayan hata mesajları ve hatanın nasıl düzeltileceğini söyleyen açıklama. Avrupa Birliği'ndeki tüketicilere satış yapan firmalar için Haziran 2025'ten beri uygulanan Avrupa Erişilebilirlik Yasası bu kuralları bir tercih olmaktan çıkarıyor.

Tasarım sistemi ve geliştiriciye devir

Tasarım sistemi, arayüzün yeniden kullanılabilir parçalarının (buton, form alanı, uyarı kutusu, adım göstergesi) kurallarıyla birlikte toplandığı kütüphanedir. Figma'da bileşen ve varyant olarak kurulur; kod tarafında aynı bileşenler çoğu zaman Storybook gibi bir araçta belgelenir. Teklif formu tek bir sayfa gibi görünse de içinde onlarca durum saklıdır.

Her bileşen için bütün durumları tasarlayın: varsayılan, üzerine gelinmiş, odaklanmış, devre dışı, hatalı, yükleniyor, başarılı. Geliştiriciye yalnızca sorunsuz durumu gösteren bir tasarım verirseniz gerisini o tahmin eder ve her geliştirici başka türlü tahmin eder.

Metin de bir bileşendir. Hata mesajlarının kalıbı (ne oldu, nasıl düzelir), buton etiketlerinin ne iş yaptığını söylemesi, zorunlu alanların nasıl işaretleneceği tasarım sisteminde yazılı olursa, siteye yeni bir form eklendiğinde aynı tartışma baştan yapılmaz.

Devir (handoff) bir dosya bağlantısı göndermekten ibaret değildir. İyi bir devir paketinde şunlar bulunur:

• Figma'nın Dev Mode görünümünde ölçüler, renk ve yazı belirteçleri, dışa aktarılacak görseller.
• Etkileşim notları: hangi alan ne zaman doğrulanır, hata mesajı ne zaman görünür, form gönderilince ne olur?
• Bütün metinler: etiketler, yardım metinleri, hata mesajları, başarı ekranı ve onay e-postası.
• Erişilebilirlik notları: odak sırası, ekran okuyucu için alan açıklamaları, hataların nasıl duyurulacağı.
• Ölçüm planı: hangi adımda hangi analitik olayının tetikleneceği.

Devirle tasarımcının işi bitmez. Geliştirme sırasında kısa kontroller yapmak ve yayından önce bütün durumları gerçek cihazlarda gözden geçirmek, tasarımla canlı sürüm arasındaki farkları küçükken yakalar.

Yayından sonra: ölçmek ve yeniden denemek

Yeni form yayına girdiğinde asıl öğrenme başlar. Neyi başarı sayacağınızı yayından önce yazın; sonradan sayıları beğendiğiniz biçimde yorumlamak çok kolaydır. Pompa örneğinde üç ölçüt seçildi: formu başlatanların ne kadarının gönderdiği, satış ekibinin kaç talepte müşteriyi geri aramak zorunda kaldığı ve talepten teklife geçen süre.

Bu ölçütlerin ikisi sitenin analitiğinde değil, satış ekibinin CRM kayıtlarında görünür. İyi bir UX ölçümü yalnızca tıklamaları değil, işin kendisini de izler.

Sayılar size nerede sorun olduğunu söyler, nedenini nadiren. Başarı ekranına tek soruluk bir geri bildirim (“İstediğiniz bilgiyi verebildiniz mi?”) eklemek ya da formu yarıda bırakıp telefonla arayan müşteriye nedenini sormak, analitiğin göstermediğini bazen tek cümleyle açıklar.

Trafik azsa A/B testinden mucize beklemeyin. Anlamlı bir sonuç için yeterli ziyaretçi gerekir ve küçük B2B sitelerinde bu çok uzun sürebilir. Böyle durumlarda birkaç ayda bir tekrarlanan küçük kullanılabilirlik testleri, satış ekibinden düzenli geri bildirim ve analitikteki belirgin değişimleri izlemek daha gerçekçi bir yoldur.

Nereden başlamalı?

1. Tek bir akış seçin: en çok gelir getiren ya da en çok şikâyet alan form, ödeme adımı veya başvuru süreci.
2. Satış ve destek ekibiyle birer saatlik görüşme yapın; akışın nerede tıkandığını onlardan dinleyin.
3. Analitikte akışın başlatılma ve tamamlanma sayılarını çıkarın. Ölçüm yoksa önce ölçümü kurun.
4. Beş altı gerçek müşteriyle son deneyimlerini konuşun ve hangi işi yapmaya çalıştıklarını tek cümleyle yazın.
5. Gerçek metinlerle tel çerçeve çizin, ardından tıklanabilir bir prototip hazırlayın.
6. Beş kişiyle test edin, düzeltin, yeniden test edin.
7. Erişilebilirlik ölçütlerini ve bileşenlerin bütün durumlarını devir paketine ekleyin.
8. Başarı ölçütlerini yayından önce yazın, yayından sonra onlara dönüp bakın.

AYTE Digital'de tasarım çalışmalarına bu sırayla, araştırma ve prototiple başlıyoruz. Elinizde sorun çıkaran bir form ya da akış varsa, onu birlikte inceleyip hangi adımın gerçekten gerektiğini, hangisinin atlanabileceğini konuşabiliriz.