Uygulama tasarımı ne kadar tutar?

Kısaca

"Bir uygulama tasarımı kaça olur?" sorusunun tek bir cevabı yok, çünkü "uygulama" kelimesi her teklifte başka bir iş anlatıyor. Biri beş ekranlık bir taslaktan söz eder, öbürü iki platformda yayına çıkmış bir üründen.

Bu yüzden fiyatı sormadan önce kapsamı yazmanızı öneririm. Kapsam yazılı olunca gelen teklifler de karşılaştırılabilir hale gelir.

• Fiyatı en çok ekran ve akış sayısı, platform, araştırma ve kod belirler. Tasarım sistemi ve erişilebilirlik hedefi ilk bakışta görünmez ama süreyi uzatır.
• ux.center'da fiyatlar açık. Aşağıdaki seçici, kapsamınızın hangi teklife uyduğunu gösterir.

Uygulama tasarım fiyatını ne belirler?

Teklifteki rakam, harcanacak saatin tahminidir. Aşağıdaki kalemlerin her biri o saati büyütür ya da küçültür.

Akış ve ekran sayısı

Akış, kullanıcının tek bir amaca ulaşmak için geçtiği ekranlar dizisidir: kayıt olmak ya da ödeme yapmak gibi. Ekran ise o dizideki tek bir görünümdür. Ben kapsamı önce akışlarla, sonra ekranlarla sayarım.

Ekran sayısı göründüğünden büyüktür. Her ekranın bir de boş, yükleniyor ve hata hali vardır. "Sepet" tek ekran gibi durur ama boş sepet ile geçersiz kupon ayrı ayrı tasarlanır.

Teklif isterken ekran adlarını tek tek listeleyin. Liste yoksa teklif veren kişi sayıyı tahmin eder ve tahmin çoğu zaman kendi lehine yuvarlanır.

Platform

Web, iOS ve Android aynı işi farklı kurallarla yapar. Android'de hareketle gezinme açıksa kullanıcı, ekranın sol ya da sağ kenarından kaydırarak geri döner. Düğmeli gezinmede ise geri tuşuna basar. Android'in geliştirici rehberi, birden fazla gezinme biçimini hesaba katmayı ister.

Aynı rehbere göre Android 15'te kenardan kenara (edge-to-edge) görünüm zorunludur ve durum çubuğu varsayılan olarak saydamdır. Rehber, içeriğin ve butonların sistem çubuklarının altında kalmadığını kontrol etmeyi ister. Bu yüzden bu alan her ekranda ayrıca düşünülür. iOS'un da kendi kuralları var. İki platformun farklarını mobil uygulama tasarımı rehberinde anlattım.

İki platform demek, ekranların bir kısmını iki kez düşünmek demektir. Kod da yazılacaksa iş daha da büyür, çünkü ortaya iki ayrı uygulama çıkar.

Kullanıcı araştırması

Araştırma, tasarımın doğru sorunu çözdüğünü ölçer. Görüşme ya da test, katılımcı bulmaktan analize kadar ayrı zaman ister. Teklifte ayrı satır olarak yazılmalıdır.

Burada en çok sorulan şey katılımcı sayısıdır. Jakob Nielsen, nitel bir kullanılabilirlik testinde 5 kullanıcıyla test etmeyi önerir. Ona göre aynı teste 5 kişiden fazlasını almanın ek faydası azdır, maliyet ise her katılımcıyla artar.

Nielsen çok özellikli büyük ürünler için tek büyük test yerine birkaç ayrı test önerir. Her test özelliklerin daha küçük bir bölümüne bakar. Bu ayrıntıları kullanılabilirlik testi rehberinde bulabilirsiniz.

Tasarım sistemi

Tasarım sistemi, tekrar kullanılan bileşenlerin ve kuralların toplamıdır: renkler, yazı tipleri, butonlar, form alanları ve bunların halleri. NN/g bunu, yeniden kullanılabilir bileşen ve kalıplarla tasarımı ölçekli yönetmeye yarayan standartlar bütünü olarak tanımlar.

NN/g aynı yazıda maliyeti de açıkça yazar. Sistem ne kadar özel yapılırsa kurması o kadar çok zaman ve para ister. Değişmesi muhtemel bir prototip ya da kavram kanıtı için tam bir sistem kısa vadede karşılığını vermez.

Benim pratiğim şu: küçük bir iş için ayrı bir sistem kurmam, ürünün kendi bileşenlerini ve design token yapısını düzenli tutarım. Ürün büyüyecekse tasarım sistemi ayrı bir kalem olarak teklife girer.

Kod

Yalnızca tasarım teslim eden bir iş, Figma dosyasıyla biter. Tasarım ve kod birlikte satılıyorsa teslim, çalışan ekranlardır. İki teklif bu yüzden aynı ekran sayısıyla çok farklı tutabilir.

Yalnızca tasarım alıyorsanız bir maliyeti de hesaba katın: tasarımı koda çevirecek ekip. Tasarımdaki ayrıntılar bu el değiştirmede kaybolabilir, düzeltmesi de yeni bir tur ister.

Erişilebilirlik hedefi

Hedefi baştan yazın. W3C'nin WCAG 2.2 standardı üç seviye tanımlar: A, AA ve AAA. AA uyumu için sayfa tüm A ve AA başarı kriterlerini karşılar. Örneğin 1.4.3 asgari kontrast ve 2.4.7 odak görünürlüğü AA seviyesindedir.

Benim deneyimimde bu kurallar sonradan eklenince daha pahalıya gelir. Seviyeleri WCAG rehberinde anlattım.

Revizyon ve kapsam değişikliği

Revizyon turu sayısı da fiyatı etkiler. Benim gözlemim şu: sınırsız revizyon vaat eden bir teklif ya fiyatı baştan yüksek tutar ya da işi uzatır. Kaç tur olduğunu ve bir turun neyi kapsadığını yazılı görün.

Kapsam değişikliği ise ayrı bir konudur. Yolda eklenen bir akışı ben yeni iş olarak sayarım. Bunun fiyata nasıl yansıyacağı da baştan konuşulmalıdır.

Piyasa fiyat aralığı neden yok?

Bu sayfada "Türkiye'de uygulama tasarımı şu kadar ile şu kadar arası" diye bir aralık yazmadım. Bunun için kamuya açık ve tarihli bir fiyat çalışması gerekir. Böyle bir kaynağı açıp okumadan rakam yazmak tahmin olur.

Ayrıca bir aralık, kapsam belli olmadığı sürece pek bir şey söylemez. Beş ekranlık bir web taslağı ile iki platformda kodlanmış bir ürün aynı aralığa girmez.

Daha işe yarar bir yol var: kapsamınızı yazın ve aynı yazıyla birkaç teklif isteyin. Sonra teklifleri aşağıdaki kalemlerle yan yana koyun.

Teklifleri nasıl karşılaştırırsınız?

İki teklifi önce içerikleriyle karşılaştırın. Ben bir teklifte şu soruların cevabını yazılı görmek isterim:

• Hangi akışlar ve hangi ekranlar tasarlanacak? Boş, yükleniyor ve hata halleri dahil mi?
• Hangi platformlar için? Web, iOS, Android ya da hepsi.
• Kullanıcı araştırması var mı? Varsa kaç görüşme ya da test oturumu?
• Tasarım sistemi kuruluyor mu, yoksa mevcut bileşenler mi kullanılıyor?
• Kod kimde? Tasarımı kim koda çeviriyor, kod hangi repoya gidiyor?
• Kaç tur revizyon var ve kapsam değişirse fiyat nasıl değişiyor?
• Teslim tarihi ne, ödeme nasıl, fiyata KDV dahil mi?

Cevabı olmayan her satır, sonradan çıkacak bir ek faturanın adayıdır. Kapsamı yazmakta zorlanıyorsanız MVP sayfası, ilk sürüme neyin gireceğini seçmenize yardım eder.

Örnek: bir kapsam nasıl yazılır?

Bir kahve zincirinin sipariş uygulaması yaptırmak istediğini düşünün. "Bize bir sipariş uygulaması lazım" cümlesiyle teklif isterse, her stüdyo kafasında başka bir uygulama hayal eder.

Aynı isteği şöyle yazmak, teklifleri karşılaştırılabilir yapar:

• Akışlar: kayıt ve giriş, menüden ürün seçme, sepet ve ödeme, sipariş durumu, sadakat puanı.
• Ekranlar: her akışın ekran listesi. Boş sepet, ödeme hatası ve kapalı şube gibi haller dahil.
• Platform: önce yalnızca iOS ve Android. Web sonraki sürüme kalır.
• Araştırma: tasarım bitince 5 kullanıcıyla bir test turu.
• Tasarım sistemi: markanın renkleri ve yazı tipleri var, bileşen kütüphanesi yok.
• Kod: mobil kod da isteniyor, mevcut sipariş sistemine bağlanacak.
• Erişilebilirlik: WCAG 2.2 AA.

Bu liste bir sayfayı geçmez ama teklif veren kişinin tahmin payını büyük ölçüde kaldırır. Hangi akışın kullanıcı için önemli olduğunu seçmekte zorlanıyorsanız bir kullanıcı yolculuğu haritası iyi bir başlangıçtır.

Listede ilk sürüme gerçekten gerekenleri işaretleyin. Sadakat puanı ilk sürümden çıkarsa, bir akış ve ona bağlı bütün ekranlar da tekliften düşer.

Kapsamınız hangi teklife uyar?

Aşağıda kapsamınızı beş soruyla seçin. Seçici fiyat tahmini vermez. Kapsamınızın hangi ux.center teklifine uyduğunu ve nedenini gösterir.

Kapsam seçici

Seçici JavaScript ile çalışır. Aynı eşleme kuralları aşağıdaki tabloda da yazıyor.

Bu seçici fiyat tahmini yapmaz, kapsamınızı ux.center tekliflerinden birine eşler. Eşleme kuralları benim kendi kurallarımdır. Her seçimde önerilen teklif ve gerekçesi değişir.

Aynı kuralları düz bir tablo olarak da yazdım:

Kapsamınız	Uyan teklif	Fiyat
1–30 ekran, tek platform, araştırma yok, kod var	Tasarla & Yayınla Sprinti	$1.999 / 2 hafta
Yalnızca tasarım, kod yok	Sabit fiyatlı proje	24 saat içinde teklif
31 ekrandan fazla	Sabit fiyatlı proje	24 saat içinde teklif
Kullanıcı araştırması var	Sabit fiyatlı proje	24 saat içinde teklif
iOS ve Android ya da web ve mobil, kod var	Sabit fiyatlı proje	24 saat içinde teklif
Ürün yayında, önce sorunları bulmak istiyorsunuz	UX Audit ya da UX Audit Pro	$79 tek akış, $399 10 akışa kadar

Kurallar bir başlangıç noktası. Sınırda kalan bir kapsamda karar 15 dakikalık görüşmede netleşir.

ux.center'da UI/UX tasarım fiyatları

Kendi fiyatlarımı açık yazıyorum. Kapsam belliyse rakam da işe başlamadan belli olur.

• UX Audit: $79, tek akış, 48 saat içinde teslim.
• UX Audit Pro: $399, uygulamanın tamamı, 10 akışa kadar, 48 saat içinde teslim.
• Tasarla & Yayınla Sprinti: $1.999 / 2 hafta. Tasarım ve kod, sizin reponuza. Bir sonraki iş günü başlar.
• Sabit fiyatlı proje: kapsamı anlatırsınız, 24 saat içinde tek bir fiyat ve teslim tarihi gönderirim.

Fiyatlar USD cinsindendir, KDV dahil değildir. 30 gün içinde sprint alırsanız audit ücretini sprint fiyatından düşerim. Tekliflerin tamamını, süreleri ve ödeme yolunu fiyatlar sayfasında tek tabloda görebilirsiniz.

Benim notum

Fiyat konuşmalarında en sık gördüğüm sorun, kapsamın hiç yazılmamış olmasıdır. "Bir uygulama istiyoruz" cümlesiyle başlayan bir iş, ilk teslimde "bunu da düşünmüştük" cümlesiyle büyür.

Bu yüzden ben önce ekran listesini isterim. Liste yoksa birlikte çıkarırız. Çoğu zaman listenin bir kısmı ilk sürüme girmez ve fiyat kendiliğinden düşer.

İkinci sık sorun, tasarımın ve kodun ayrı ayrı fiyatlanıp ayrı ekiplerce yürütülmesidir. Tasarım teslim edilir, kod ekibi aylar sonra başlar ve ekranların bir kısmı yeniden düşünülür. Tasarımı da kodu da kendim yaptığım için bu el değiştirme bende yok.

Ürününüz yayındaysa yeniden tasarımdan önce bir audit öneririm. Neyin bozuk olduğunu bilmeden çizilen yeni ekranlar, eski sorunları yeni bir görünüme taşır. Bu konuyu önce audit, sonra tasarım yazısında açtım.