UX/UI hizmeti: araştırmayla kurulan, kullanıcıyla sınanan arayüz.

Bu rehberi, sitesinin ya da uygulamasının kullanıcıyı neden yorduğunu kanıta dayanarak görmek isteyen ürün, pazarlama ve kurumsal site ekipleri için yazdık. UX UI tasarım sürecini anlatırken insan odaklı tasarım standardı ISO 9241-210’a, W3C’nin erişilebilirlik belgelerine ve WCAG 2.2’ye (Web İçeriği Erişilebilirlik Yönergeleri), GOV.UK Service Manual’ın kullanıcı araştırması rehberlerine, Apple Human Interface Guidelines’a, Google’ın Material Design sistemine ve Figma’nın yardım merkezi Figma Learn’e dayanıyoruz; kaynaklar sayfanın altında numaralıdır. Ürün adlarını ve özellikleri Eylül 2026 itibarıyla kaynaktan doğruladık. Kendi saha gözlemlerimizi “Uzman notu” başlığıyla ayrı işaretledik.

İşimiz üç katmanda ilerler: kullanıcının görevini ve takıldığı yeri bulan araştırma, görevi prototipte sınayan bilgi mimarisi ve etkileşim, kararları bileşenlere ve erişilebilirlik kurallarına bağlayan arayüz ve tasarım sistemi.

UI UX nedir, UX ile UI arasındaki fark ne?

UX (kullanıcı deneyimi, user experience) bir kişinin ürünü kullanırken yaşadığı deneyimin bütünüdür; UI (kullanıcı arayüzü, user interface) ise bu deneyimin geçtiği ekranlar, bileşenler ve etkileşimlerdir. UX’i ölçülebilir kılan kavram kullanılabilirliktir: W3C kullanılabilirliği etkili, verimli ve memnuniyet veren ürünler tasarlamak olarak tanımlar ve kullanıcı deneyimi tasarımını da bu alanın içinde sayar.² W3C’nin aktardığı ISO 9241-11 tanımına göre kullanılabilirlik, bir ürünün belirli kullanıcılar tarafından belirli hedeflere, belirli bir kullanım bağlamında etkili, verimli ve memnuniyetle ulaşmak için kullanılabilme derecesidir.² Tanımdaki üç koşul UX’i zevk tartışmasından çıkarır: kullanıcı işi bitirebildi mi, ne kadar emekle bitirdi, memnun kaldı mı.

UI bu soruların görünen yüzüdür: düğmenin yeri, hatanın gösterimi, klavyeyle gezinirken odağın görünürlüğü. İyi görünen ama görevi uzatan bir arayüz UX sorunu taşır; UX tasarımı ile UI tasarımını bu nedenle aynı çalışmanın iki katmanı olarak yürütüyoruz.

İnsan odaklı tasarım süreci neye dayanır?

İnsan odaklı tasarım süreci, kararların kullanıcıdan gelen kanıtla alındığı ve ürünün ömrü boyunca tekrarlanan bir araştırma, tasarım ve değerlendirme döngüsüne dayanır. ISO 9241-210:2019, bilgisayar tabanlı etkileşimli sistemlerin yaşam döngüsü boyunca insan odaklı tasarım ilkeleri ve etkinlikleri için gereklilikler ve öneriler ortaya koyar; tasarım süreçlerini yönetenler için yazılmıştır.¹ Standart yöntem ve tekniklerin ayrıntısına girmez; ayrıntılı kullanılabilirlik ve erişilebilirlik konularını ISO 9241’in öteki bölümlerine ve başka standartlara bırakır.¹ Temmuz 2019’da yayımlanan ikinci baskı 2025’te gözden geçirilerek onaylandı.¹

Yöntem tarafını GOV.UK Service Manual’ın kamu hizmetleri için yazdığı araştırma rehberleriyle kuruyoruz. GOV.UK, kullanıcılardan gelmeyen her görüş ve öneriyi araştırmayla kanıtlanması gereken bir varsayım saymayı önerir.³ Bu ilke toplantıların dilini değiştirir: “bence” ile başlayan öneri reddedilmez, sınanacaklar listesine yazılır.

UX araştırması neyle başlar?

UX araştırması yeni veri toplamadan önce eldeki kanıtı okumakla başlar. GOV.UK, kullanıcıları tanımanın yolları olarak analitik, arama kayıtları, çağrı merkezi verisi ve önceki araştırma raporları gibi mevcut kanıtı gözden geçirmeyi, gerçek ya da olası kullanıcılarla görüşüp onları gözlemlemeyi ve bu kullanıcılarla çalışan kişilerle konuşmayı sayar.³ Rehber kullanıcı ihtiyacını, kullanıcının doğru sonuca ulaşması için hizmetin karşılaması gereken ihtiyaç olarak tanımlar ve ihtiyaçların kullanıcının tanıyacağı, kendisinin de kullanacağı sözcüklerle yazılmasını ister.³

Her yöntem sorunun bir yüzünü gösterir; önceliklendirmeden önce aynı sorunu en az iki yöntemin göstermesini bekliyoruz:

Oturum kaydı ve huni analizini CRO danışmanlığı sayfamızda anlattık.

Kullanıcı görüşmesi nasıl yapılır?

Kullanıcı görüşmesi, katılımcıya ne istediğini sormadan, işini bugün nasıl yaptığını yaşanmış örneklerle anlatmasını sağlayan sorularla yapılır. GOV.UK’ye göre derinlemesine görüşmeler farklı kullanıcı türlerini, koşullarını, bir hizmeti nasıl kullandıklarını ve ondan neye ihtiyaç duyduklarını öğrenmeye yarar; konunun karmaşıklığına ve soru sayısına göre 30 dakika ile 2 saat arasında sürebilir.⁴ Rehber “nasıl yapıyorsunuz?” gibi açık ve tarafsız soruları, “biraz daha anlatır mısınız?” gibi devam sorularını önerir; işlerin nasıl “olması gerektiği” yerine hikâyelere ve gerçek örneklere odaklanmayı ister.⁴

GOV.UK, görüşmenin moderatörlü kullanılabilirlik testiyle birleştirilebileceğini yazar: katılımcıyla önce konuşulur, ardından bir prototipi ya da hizmeti denemesi istenir.⁴

Kullanıcı akışı ve tel çerçeve nasıl kurulur?

Kullanıcı akışı, bir görevin giriş noktasından hedef ekrana kadar geçtiği adımlar, karar noktaları ve hata yollarıyla tek şemada çizilerek kurulur; tel çerçeve (wireframe) ise her adımı renk ve görselden arındırılmış bir ekran taslağına çevirir. Bir akışı beş parçayla çiziyoruz:

1. Giriş noktası: arama sonucu, reklam, e-posta bağlantısı ya da uygulama bildirimi; her giriş noktası ayrı çizilir.
2. Adımlar: kullanıcının gördüğü her ekran ya da ekran durumu; açılan bir pencere de ayrı bir adımdır.
3. Karar noktaları: üye mi misafir mi, stok var mı yok mu gibi akışı dallandıran sorular; her dalın bir sonu olmalıdır.
4. Hata ve boş durumlar: hatalı giriş, sonuç bulunamaması, bağlantının kopması; çoğu projede çizilmeyen, kullanıcının ise sık takıldığı ekranlar.
5. Hedef ekran: görevin tamamlandığını açıkça gösteren ekran; ölçümdeki anahtar etkinlik de burada tanımlanır.

Tel çerçevede yalnız içerik önceliğine, gezinmeye ve form yapısına karar veriyoruz; renk ve görsel olmadığı için paydaşların dikkati akışın doğruluğunda kalır. Prototipe geçmeden önce her ekranın bir ihtiyaca ve akıştaki bir adıma bağlandığını kontrol ediyoruz; bağlanamayan ekran akıştan çıkar.

Prototip neden tıklanabilir olmalı?

Prototip tıklanabilir olmalıdır, çünkü kullanıcı gerçek davranışını ancak akışın içinde gezinirken gösterir; durağan bir ekran üzerine yapılan yorum görüş olarak kalır. Figma’ya göre prototip özellikleri, kullanıcının tasarımla nasıl etkileşime gireceğini denemeye yarayan etkileşimli akışlar kurmayı sağlar; bu akışlarla ekipten geri bildirim alınır ve etkileşimler kullanıcılarla sınanır.⁵ Figma’nın prototip kavramlarından dördü bir bağlantının nasıl çalıştığını anlatır:⁵

• Bağlantı (connection): etkileşim noktasını hedef ekrana bağlayan ok.
• Tetikleyici (trigger): prototipi ilerleten etkileşim; tıklama, dokunma, üzerine gelme ya da sürükleme gibi.
• Eylem (action): ilerlemenin türü; başka bir ekrana geçmek ya da dış bir adres açmak gibi.
• Hedef (destination): doğrudan tuvale eklenmiş üst düzey bir çerçeve olmalıdır; çerçevenin içindeki bir nesne hedef olamaz.

Figma’da bir sayfadaki çerçeveler ve bağlantılar ağına akış (flow) denir; bir prototipte farklı görevleri gösteren birden çok akış olabilir ve her akış bir başlangıç noktasından açılır.⁵ Test için prototipin tamamı ya da tek bir akışın başlangıç noktasına giden bağlantı paylaşılabilir.⁵ Ziyaretçisi çoğunlukla telefondan gelen sitelerde testi telefonda yapıyoruz; masaüstünde sınanan akış, dokunmatik ekranda başka yerlerde takılabilir.

Kullanılabilirlik testi nasıl yürütülür?

Kullanılabilirlik testinde katılımcıya gerçekçi bir görev verilir, görevi denerken sesli düşünmesi istenir ve oturumu yöneten moderatör çoğunlukla susarak nerede takıldığını gözler. GOV.UK moderatörlü testi, katılımcıların hizmeti kullanarak belirli görevleri tamamlamaya çalışmasının izlendiği yöntem olarak tanımlar; test, kullanıcıların ne yapmaları gerektiğini anlayıp anlamadığını görmeye, dil ve yerleşim sorunlarını bulmaya yarar.⁶ Sesli düşünme, katılımcının ne yaptığını, ne düşündüğünü ve ne hissettiğini anlamayı kolaylaştırır.⁶ Testi GOV.UK’nin önerileri üzerine şöyle kuruyoruz:⁶

W3C’ye göre kullanılabilirlik süreçleri ve kullanıcı katılımı tek başına bütün erişilebilirlik sorunlarını çözemez.² Bu nedenle mümkün olduğunda ekran okuyucu ya da büyütme kullanan katılımcıları teste dahil ediyor, arayüzü her durumda WCAG 2.2’ye göre ayrıca denetliyoruz.

Tasarım sistemi ve bileşen kütüphanesi ne kazandırır?

Tasarım sistemi aynı kararın her ekranda yeniden alınmasını önler: bir düğme, alan ya da kart bir kez tanımlanır ve her yerde aynı kaynaktan kullanılır. Figma’da ana bileşen özellikleri tanımlar; örnekler (instance) ana bileşene bağlı kopyalardır ve ona yapılan güncellemeleri alır.⁷ Bileşenler ekip kütüphanesiyle dosyalar ve klasörler arasında paylaşılabilir.⁷

Bileşenin altındaki katman tasarım belirteçleridir (design tokens). Material Design, belirteçleri bir tasarım sisteminin görsel stilini oluşturan küçük, yeniden kullanılabilir tasarım kararları olarak tanımlar; her belirteç kod benzeri bir ad ile bir değerden oluşur ve üç sınıfa ayrılır:⁸

Material’e göre tasarımcının çizimi ile mühendisin kodu aynı belirtece bağlandığında, değer sonradan güncellense bile iki taraf aynı rengi kullanır; belirteçler devirde karışıklığı da azaltır.⁸ Aynı belgeye göre sabit değerlerle yazılmış, önümüzdeki bir iki yılda değişmesi beklenmeyen bir uygulamada ya da tasarım sistemi olmayan bir üründe belirteçlerin yararı azalır.⁸ Sistemin kapsamını bu nedenle ürünün büyüklüğüne göre seçiyoruz.

Material Design, bir bileşenin etkileşim durumunu göstermek için altı durum tanımlar: etkin, devre dışı, üzerine gelme (hover), odaklanmış, basılı ve sürüklenen.⁹ Erişilebilirlik için her durumun iki görsel göstergesi olur; seçim ile üzerine gelme gibi durumlar da birleşebilir.⁹

Erişilebilirlik arayüze nasıl işlenir?

Erişilebilirliği, tasarım bittikten sonra denetlemek yerine bileşenin ölçülerine, renklerine ve durumlarına baştan kural olarak yazıyoruz; ölçütümüz WCAG 2.2’dir. WCAG 2.2, 5 Ekim 2023’te W3C Tavsiyesi (W3C Recommendation) olarak yayımlandı ve dokuz yeni başarı ölçütü ekledi; 2.0 ve 2.1 ölçütleri, kaldırılan 4.1.1 Ayrıştırma (Parsing) dışında temelde aynı kaldı.¹⁰ Yeni ölçütlerden dördü AA düzeyindedir ve arayüzü doğrudan etkiler:¹⁰

• 2.4.11 Odak gizlenmemeli (en az, AA): klavye odağını alan bileşen, sayfanın kendi içeriği tarafından tamamen gizlenmez; yapışkan başlıkları ve alt bantları bu ölçüte göre denetliyoruz.
• 2.5.7 Sürükleme hareketleri (AA): sürüklemeyle yapılan her işlev, sürükleme zorunlu olmadıkça sürüklemeden tek bir işaretçiyle de yapılabilir.
• 2.5.8 Hedef boyutu (en az, AA): işaretçiyle seçilen hedef, aralık, eşdeğer kontrol ve satır içi metin gibi tanımlı istisnalar dışında en az 24 × 24 CSS pikseldir.
• 3.3.8 Erişilebilir kimlik doğrulama (en az, AA): kimlik doğrulamanın hiçbir adımında, o adım tanımlı seçeneklerden birini sunmadıkça bilişsel işlev testi istenmez.

A düzeyindeki iki yeni ölçüt de denetimimizde yer alır: 3.2.6 Tutarlı yardım, sayfalarda tekrarlanan yardım mekanizmalarının öteki içeriğe göre aynı sırada durmasını; 3.3.7 Gereksiz yeniden giriş, aynı süreçte yeniden istenen bilginin tanımlı istisnalar dışında otomatik doldurulmasını ya da seçilebilir olmasını ister.¹⁰

Apple Human Interface Guidelines her platform için ayrı bir varsayılan ve en küçük kontrol boyutu önerir: iOS ve iPadOS’ta varsayılan boyut 44×44 pt, en küçük boyut 28×28 pt’dir.¹¹ Apple’ın Accessibility Inspector (erişilebilirlik denetleyicisi) aracı kontrastı değerlendirirken WCAG AA değerlerini ölçü alır: 17 punto ve altındaki metinde en az 4,5:1, 18 punto metinde ve her boyuttaki kalın metinde 3:1.¹¹ Belge, metnin idealde en az yüzde 200 (watchOS’ta 140) büyütülebilmesini de önerir.¹¹

Web arayüzünde WCAG 2.2 AA’yı alt sınır kabul ediyor, telefonda sık kullanılan birincil düğmelerde Apple’ın varsayılan değerine yakın dokunma alanları bırakıyoruz.

İlk 30 gün ve geliştirmeye devir nasıl ilerler?

İlk 30 gün araştırma, akış ve test döngüsüne ayrılır; ardından onaylanan tasarım, hiçbir durumu tahmine bırakmayan bir teslimle geliştirmeye devredilir. İlk dört hafta şu sırayla ilerler:

1. 1. hafta · Kanıt ve plan: analitik, destek kayıtları ve önceki araştırmalar okunur; öncelikli görevler ve görüşme kılavuzu çıkarılır.
2. 2. hafta · Görüşme ve ihtiyaçlar: kullanıcı görüşmeleri yapılır, bulgular kullanıcı ihtiyacı kalıbına çevrilir.
3. 3. hafta · Akış ve prototip: öncelikli görevlerin akışları ve tel çerçeveleri çizilir, Figma’da tıklanabilir prototip kurulur.
4. 4. hafta · Test ve karar: prototip kullanılabilirlik testinde sınanır; sonraki aşamanın kapsamı birlikte belirlenir.

Devirde kullandığımız Figma Dev Mode (geliştirici modu), Figma’ya göre tasarım dosyalarında gezinmek ve tasarımı koda dönüştürmek için geliştiriciye yönelik bir arayüzdür: biten bölüm, çerçeve ve bileşenler “Ready for dev” (geliştirmeye hazır) olarak işaretlenir, açıklamalarla (annotations) ölçü ve notlar eklenir, çerçeve sürümleri karşılaştırılabilir.¹² Dev Mode bütün ücretli planlarda bulunur ve Full ya da Dev koltuğu (seat) gerektirir.¹²

Sitenin bütününü kapsayan işleri kurumsal web sitesi sayfamızda anlatıyoruz. Bir UX/UI ortağı seçerken şu soruların yanıtlarını karşılaştırmak işe yarar: kararlar hangi araştırmaya dayanıyor, erişilebilirlik hangi ölçütle denetleniyor, işi kim yürütüyor, dosyalar ve hesaplar kimin adına açılıyor.

Kullanıcılarınızın hangi görevde zorlandığını birlikte görmek isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz; ilk görüşmede öncelikli görevleri ve eldeki veriyi netleştiriyoruz.