Dijital Ürün Tasarım Süreci: Araştırmadan Geliştirici Devrine

Ürün tasarımı denince çoğu kişinin aklına ekranlar gelir. Oysa iyi görünen ekranlar, sürecin en son ve en kolay görülen kısmıdır. Bir ürünün başarısını belirleyen kararların çoğu ekran çizilmeden önce verilir: hangi sorunu çözdüğü, kimin için yapıldığı, kullanıcının hangi yoldan hedefine ulaşacağı. Bu kararlar yanlışsa en güzel arayüz bile yanlış yeri güzelleştirir.

Bu rehber, bir dijital ürünün tasarımında izlediğimiz süreci aşama aşama anlatıyor. Bizimle çalışmasanız da bir stüdyodan ya da kendi ekibinizden ne bekleyeceğinizi netleştirmek için kullanabilirsiniz. Kısa bir öz değerlendirme için UX ön kontrolünü, bir denetim raporunun nasıl göründüğü için örnek UX denetimini inceleyebilirsiniz.

Süreç neden önemli?

Uluslararası standart ISO 9241-210, etkileşimli sistemler için insan odaklı tasarımı tanımlar. Standart, tasarımın kullanıcıların, görevlerin ve kullanım ortamının açıkça anlaşılmasına dayanmasını, kullanıcıların süreç boyunca dahil edilmesini, tasarımın kullanıcı odaklı değerlendirmeyle yönlendirilmesini ve sürecin tekrarlı olmasını ister 1. Kısacası tek seferlik bir çizim değil, öğrenerek ilerleyen bir döngü.

Birleşik Krallık Tasarım Konseyi'nin yaygın olarak kullanılan Çift Elmas modeli de aynı fikri iki aşamada anlatır: önce sorunu keşfedip tanımlamak, sonra çözümü geliştirip sunmak 2. İlk elmas doğru şeyi yapmayı, ikinci elmas şeyi doğru yapmayı amaçlar. Pratikte bu, şu sıralamaya dönüşür:

1. Keşif: doğru soruyu yazmak

Keşif aşamasının amacı çözüm üretmek değil, sorunu ve sınırları netleştirmektir. GOV.UK'nin hizmet tasarımı rehberi, keşif aşamasında henüz bir şey inşa etmemeyi; kullanıcıların neyi başarmaya çalıştığını, çözülmesi gereken sorunu ve kısıtları anlamayı önerir 4.

Bu aşamada yazılı hâle getirdiklerimiz:

1. Ürünün iş hedefi ve başarının nasıl ölçüleceği.
2. Kullanıcı rolleri ve her rolün ana görevleri.
3. Mevcut veri: analitik, destek talepleri, mağaza yorumları, satış ekibinin gözlemleri.
4. Teknik kısıtlar: kullanılan bileşen kütüphanesi, platformlar, geliştirme düzeni.
5. Karar verecek kişiler ve onay noktaları.

Keşfin en sık atlanan çıktısı, "yapmayacağımız şeyler" listesidir. Kapsam dışı kalan özellikleri baştan yazmak, projenin ortasında büyüyen talepleri yönetmeyi kolaylaştırır.

2. Araştırma: tahmin yerine kanıt

Araştırma, ekibin varsayımlarını kullanıcıdan gelen kanıtla sınamaktır. Nielsen Norman Group, araştırma yöntemlerini iki eksen üzerinde sınıflandırır: insanların ne söylediğine mi ne yaptığına mı baktığı (tutum ve davranış) ve sonuçların nitel mi nicel mi olduğu. Doğru yöntem, ürünün aşamasına ve cevaplanacak soruya göre seçilir 3.

Fikir aşamasındaki bir ürün için kullanıcı görüşmeleri ve bağlam gözlemi, yayındaki bir ürün için analitik inceleme, destek talepleri ve kullanılabilirlik testi daha fazla bilgi verir. Araştırmanın çıktısı, her bulgunun kaç katılımcıda ve hangi kanıtla görüldüğünü gösteren, tasarım kararlarına çevrilmiş bir listedir. Yöntemlerin ayrıntısı UX araştırması nasıl yapılır ve kullanıcı görüşmesi yazılarımızda.

3. Akış ve prototip: ekrandan önce yol

Araştırma bulguları netleştiğinde ilk tasarım çıktısı ekran değil akıştır. Kullanıcı uygulamayı hangi anda, hangi amaçla açıyor; nerede karar veriyor, nerede bırakıyor? Kullanıcı akışı, ana yolun yanında hata ve uç durumları da gösterir: bağlantı yoksa, liste boşsa, ödeme reddedilirse ne olacak?

Akış onaylandıktan sonra tel kafes ve ardından tıklanabilir prototip gelir. Prototipin amacı güzel görünmek değil, test edilebilir olmaktır. Bu aşamada görsel ayrıntıya yatırım yapmak, akış değiştiğinde boşa gider. Ayrıntılar için kullanıcı akışı nasıl çizilir ve wireframe, mockup ve prototip farkı.

4. Test: kod yazılmadan sorun bulmak

Kullanılabilirlik testi, temsilî kullanıcılardan prototip üzerinde gerçekçi görevleri yapmalarını isteyip gözlemlemektir. Jakob Nielsen'in sık alıntılanan analizine göre, sorun bulmaya yönelik nitel testlerde az sayıda kullanıcıyla yapılan testler sorunların önemli bir kısmını ortaya çıkarır; en verimli yaklaşım büyük tek bir test yerine az katılımcıyla tekrarlanan küçük testlerdir 5. Bu kural nicel ölçümler ve birden fazla kullanıcı grubu için geçerli değildir; ayrıntısını kaç kullanıcıyla test yapılmalı yazısında anlattık.

Test sonucunda her bulgu önem derecesi, kanıtı ve önerisiyle yazılır; kritik bulgular düzeltildikten sonra kısa bir tekrar testi yapılır. Prototip aşamasında bulunan bir akış hatası, yayındaki üründe bulunandan çok daha az emekle düzeltilir.

5. Arayüz ve sistem: tutarlılığı baştan kurmak

Akış test edildikten sonra arayüz tasarımına geçilir. Bu aşamada üç şeye özellikle dikkat ederiz:

• Platform alışkanlıkları. iOS ve Android'in gezinme, geri hareketi ve sistem bileşenleri farklıdır; kullanıcı kendi platformunun davranışını bekler.
• Erişilebilirlik. Hedefimiz WCAG 2.2 AA düzeyidir. WCAG 2.2, dokunma hedefinin asgari boyutu ve sürükleme hareketlerine alternatif gibi mobil açıdan önemli ölçütler ekledi 6. Ayrıntılar mobil uygulama erişilebilirliği yazımızda.
• Tüm durumlar. Her ekranın boş, yükleniyor, hata, yetki yok ve uzun içerik durumları tasarlanır.

Tekrar eden kararlar bileşen kütüphanesine ve tasarım token'larına dönüştürülür. W3C bünyesindeki Design Tokens topluluk grubu, Ekim 2025'te araçtan bağımsız token formatının ilk kararlı sürümünü (2025.10) yayımladı 7. Bu bir W3C standardı değil, topluluk grubu raporudur; ama token'ların tasarım aracından koda taşınabilir bir biçimde teslim edilmesini kolaylaştırır. Design system'in ne zaman gerektiğini design system nedir yazısında tartıştık.

6. Devir: geliştirici tahmin etmemeli

Tasarım ancak doğru uygulandığında işe yarar. Devirde eksik kalan her durum, geliştiricinin kendi yorumuyla doldurduğu bir boşluktur. Bizim devir paketimiz şunları içerir:

Mobil uygulamalarda devir, mağaza gereksinimlerini de hesaba katmalıdır. Örneğin Apple'ın uygulama inceleme yönergeleri, hesap oluşturmayı destekleyen uygulamaların hesap silmeyi de uygulama içinde sunmasını şart koşar 8. Bu tür kurallar tasarımın son anda eklenen parçaları değil, baştan çizilmesi gereken akışlardır. 2026 gereksinimlerinin toplu hâli App Store ve Google Play gereksinimleri yazımızda.

Yayından sonra: ölçüm ve tekrar

Süreç yayınla bitmez. Kayıt ve ana görev akışlarında kullanıcının nerede kaybolduğu, destek taleplerinin hangi konularda yoğunlaştığı ve yapılan değişikliklerin işe yarayıp yaramadığı ölçülmelidir. Bu veriler bir sonraki döngünün araştırma sorularıdır. Hangi metriklerin seçileceğini UX nasıl ölçülür yazısında anlattık.

Süreci her projede ürünün olgunluğuna göre uyarlıyoruz: yeni bir ürün için keşif ve araştırma ağırlıklı, yayındaki bir ürün için denetim ve test ağırlıklı. Hangi aşamadan başlamanız gerektiğini konuşmak isterseniz iletişim sayfamızdan görüşme planlayabilirsiniz; hizmetlerin ayrıntısı için UX denetimi ve mobil uygulama tasarımı sayfalarına bakabilirsiniz.