Mobil Uygulama Tasarımı: UI/UX Süreci Adım Adım

Mobil uygulama tasarımı, tek satır kod yazmadan önce uygulamanın nasıl çalışacağını ve nasıl görüneceğini beş adımda netleştirir: keşif, wireframe, etkileşimli prototip, görsel tasarım ve developer teslimi. Bu süreç toplam bütçenin yaklaşık %20-25'ini tutar ve kapsama göre 2 ila 8 hafta sürer.

Kullanıcılar bir uygulamaya karar vermek için size çok kısa bir süre tanıyor. AppsFlyer verilerini derleyen Business of Apps'e göre iOS uygulamaları ilk gün kullanıcılarının ortalama %25,4'ünü, 30. günde ise yalnızca %5,3'ünü koruyor. Android'de aynı oranlar %20,2 ve %3,8. Yani indirme başına ödediğiniz reklam bütçesinin büyük kısmı, ilk birkaç oturumda kaybettiğiniz kullanıcılara gidiyor.

Bu kaybın hepsi tasarım kaynaklı değil. Ancak ilk oturumda yaşanan kafa karışıklığı, tasarım masasında çözmeniz gereken bir sorun. Hangi ekranın önce açılacağı, kayıt formunun kaç alan isteyeceği, ana butonun başparmağın ulaştığı yerde durup durmadığı kod aşamasında değil, tasarım aşamasında karara bağlanır.

Bu rehberi uygulama yaptırmayı planlayan işletme sahipleri ve girişimciler için hazırladık. Tasarımcı olmanız gerekmiyor. Her adımda neyi onayladığınızı, hangi çıktıyı teslim almanız gerektiğini ve bütçenin nereye gittiğini anlatıyoruz.

Bu rehberde neler var?

• Mobil uygulama tasarımı nedir, neleri kapsar?
• Tasarım neden koddan önce gelir?
• 1. Adım: Keşif ve kullanıcı akışları
• 2. Adım: Wireframe ile iskeleti kurmak
• 3. Adım: Etkileşimli prototip ve kullanıcı testi
• 4. Adım: Görsel tasarım ve tasarım sistemi
• 5. Adım: Developer teslimi (handoff)
• iOS ve Android tasarım farkları
• Mobil uygulama tasarımı bütçede ne kadar yer tutar?
• Figma ile süreç şeffaflığı: müşteri olarak neyi görürsünüz?
• Yapay zeka ile mobil uygulama tasarımı: nerede işe yarar?
• Tasarım aşamasında sık yapılan 7 hata
• Sıkça Sorulan Sorular

Mobil uygulama tasarımı nedir, neleri kapsar?

Mobil uygulama tasarımı iki katmandan oluşur. UX (kullanıcı deneyimi) katmanı, kullanıcının bir işi kaç adımda ve ne kadar zahmetsiz tamamladığıyla ilgilenir. UI (kullanıcı arayüzü) katmanı ise renk, tipografi, ikon ve boşluk gibi görünen yüzü kurar. İkisinin farkını ve işletmeye katkısını UX tasarımı rehberimizde ayrıntılı anlattık; bu yazı mobil projedeki sürece odaklanıyor.

Eksiksiz bir tasarım çalışması şu çıktıları üretir:

• Kullanıcı akışları: Kayıt, arama, satın alma gibi kritik işlerin adım adım haritası.
• Wireframe seti: Tüm ekranların renksiz iskeleti.
• Etkileşimli prototip: Telefonunuzda gezdiğiniz, kod içermeyen uygulama maketi.
• Görsel tasarım: Markanızı taşıyan nihai ekranlar, açık ve koyu tema.
• Tasarım sistemi: Buton, form alanı, kart gibi tekrar eden bileşenlerin kütüphanesi.
• Teslim paketi: Geliştiricinin ölçü, renk kodu ve görsel dosyalarını çektiği düzenli kaynak dosya.

Logo ve kurumsal kimlik bu kapsamın dışındadır; tasarımcı mevcut kimliğinizi uygulamaya uyarlar. Kod yazımı da kapsam dışıdır, ama iyi bir tasarım dosyası geliştiricinin işini doğrudan hızlandırır.

Mobil tasarım, web tasarımının küçültülmüş bir kopyası da değildir. Ekran dardır, kullanıcı çoğu zaman tek eliyle ve yürürken kullanır, bağlantı kopar, araya telefon görüşmesi girer. Kamera, konum ve push izni gibi sistem pencereleri akışın parçasıdır. iOS ve Android kendi alışkanlıklarını dayatır. Bu koşulların her biri, tasarım aşamasında ayrı bir karar ister.

Tasarım neden koddan önce gelir?

İlk neden maliyet. Figma'da bir ekranın yerleşimini değiştirmek tasarımcının birkaç saatini ister. Aynı değişikliği kodlanmış, backend'e bağlanmış ve test edilmiş bir ekranda yapmak ise geliştirici, test uzmanı ve yeni bir mağaza sürümü demektir. Kararları ucuz olduğu aşamada vermek, projenin en basit tasarruf yöntemidir.

İkinci neden kapsam netliği. Yazılı bir özellik listesi herkesin kafasında farklı bir uygulama canlandırır. Ekranları gördüğünüzde "sepete ekledikten sonra ne olacak?" gibi sorular kendiliğinden ortaya çıkar. Ekran listesi netleşmiş bir proje için topladığınız teklifler de birbirine yaklaşır; çünkü firmalar aynı şeyi fiyatlar. Fiyatı oluşturan diğer kalemleri mobil uygulama fiyatları rehberimizde anlattık.

Üçüncü neden kullanıcı kaybı. AppsFlyer'ın 2025 uygulama kaldırma raporu, Android'de yüklenen uygulamaların 2024'te ortalama %46,1'inin ilk 30 gün içinde silindiğini gösteriyor. Rapora göre silmelerin çoğu ilk gün yaşanıyor ve en sık neden, karşılanmayan beklenti. İlk gün deneyimi ise büyük ölçüde onboarding, kayıt ve ana ekran tasarımının sonucudur.

İlk oturumu şekillendiren üç tasarım kararı vardır. Birincisi kayıt zamanlaması: kullanıcıya uygulamayı gezdirmeden üyelik formu göstermek, değeri görmeden emek istemektir. Misafir modu veya ertelenmiş kayıt bu sürtünmeyi azaltır. İkincisi ilk ekranın içeriği: kullanıcı uygulamayı açtığında yapmaya geldiği işi görmeli, kampanya afişini değil.

Üçüncüsü boş ekranlar. Henüz siparişi, rezervasyonu veya favorisi olmayan yeni kullanıcı, uygulamanın en çok ekranını boş görür. Bu ekranlara "Henüz kayıt yok" yazmak yerine ilk adımı gösteren bir yönlendirme koyun. Bu kararların hiçbiri kod gerektirmez; hepsini tasarım dosyasında çözersiniz. Kodlandıktan sonra fark ettiğinizde ise her biri ayrı bir geliştirme işidir.

Dördüncü neden mağaza onayı. Apple'ın App Store inceleme kurallarının tasarım bölümü, uygulamanın "yeniden paketlenmiş bir web sitesinin" ötesine geçmesini şart koşar. Bu ölçütü karşılamayan uygulamalar ret yanıtıyla karşılaşır. Sık görülen diğer ret nedenlerini App Store uygulama reddi yazımızda topladık.

1. Adım: Keşif ve kullanıcı akışları

Tasarımcı ilk hafta ekran çizmez; soru sorar. Uygulama kimin hangi sorununu çözecek? Kullanıcı bu işi bugün nasıl hallediyor? Rakip uygulamalar hangi adımda zorluyor? Bu soruların yanıtları, sonraki dört adımın pusulasıdır.

Rehber boyunca tek bir örnek üzerinden ilerleyelim: Bursa'da üç şubesi olan bir spor salonu zinciri, üyeleri için uygulama yaptırıyor. Keşif görüşmelerinde üç kritik iş öne çıkıyor: grup dersine yer ayırmak, salona QR kodla girmek ve üyeliği yenilemek. Üyeler bugün ders için resepsiyonu arıyor; hat meşgulken vazgeçiyor.

Bu aşamanın çıktıları şunlardır:

• Kullanıcı akışları: Her kritik iş için başlangıçtan bitişe adım şeması. "Ders ayırma" akışı uygulamayı açmakla başlar, onay ekranıyla biter; hedef en fazla üç dokunuş.
• Ekran listesi: Akışlardan çıkan tüm ekranların dökümü. Örneğimizde bu liste 22 ekrandan oluşuyor.
• Navigasyon kararı: Ana bölümler alt sekme çubuğunda mı duracak, kaç sekme yer alacak?
• Öncelik sıralaması: İlk sürüme girecek ve sonraki fazlara bırakacağınız özellikler.

Öncelik sıralaması bütçeyi en çok etkileyen karardır. Beslenme programı ve uygulama içi mağaza gibi fikirler cazip görünür, ama ilk sürümde üç kritik işi kusursuz yapmak daha değerlidir. Kapsamı daraltmanın yöntemini MVP rehberimizde anlattık.

Siz bu adımda ekran listesini ve öncelikleri onaylarsınız. Listede yer almayan bir ekranı sonradan eklemek mümkündür, ancak her ekleme tasarım ve geliştirme süresine yansır. O yüzden listeyi ekibinizle birlikte, gerçek bir iş günü senaryosu üzerinden okuyun.

2. Adım: Wireframe ile iskeleti kurmak

Wireframe, ekranın gri kutular ve düz yazılarla çizdiğimiz iskeletidir. Renk, fotoğraf ve marka öğesi içermez. Bu yoksunluk bilinçlidir: renkli bir ekran gördüğünüzde dikkatiniz butonun tonuna kayar, asıl soru olan "bu buton burada mı durmalı?" gözden kaçar.

Wireframe aşamasında her ekran için şu kararlar netleşir:

• Ekranda hangi bilgiler yer alıyor ve hangisi en üstte duruyor?
• Ekranın tek bir ana eylemi var mı? "Yer Ayır" butonu mu önde, "Takvime Ekle" mi?
• Kullanıcı bu ekrana nereden ulaşıyor, buradan nereye gidiyor?
• Liste boşken, bağlantı koptuğunda veya hata oluştuğunda ekran ne gösteriyor?

Wireframe'leri incelerken gerçek içerik isteyin. "Lorem ipsum" ile dolu bir ekran her zaman düzgün görünür. Türkçe metinler ise İngilizce karşılıklarından uzundur: "Book" sığan bir butona "Rezervasyonu Onayla" sığmaz. "Yetişkinler İçin Reformer Pilates (Orta Seviye)" gibi gerçek bir ders adı, kart tasarımının sınırını ilk günden gösterir.

Bu adım, değişiklik istemenin en ucuz olduğu andır. Bir kutuyu taşımak dakikalar sürer. Aklınıza yatmayan her akışı şimdi söyleyin. "Renklisini görünce karar veririm" demek, kararı pahalı aşamaya ertelemektir.

Teslim aldığınız çıktı, ekran listesindeki tüm ekranların wireframe'i ve aralarındaki bağlantıları gösteren akış şemasıdır. Eksik ekranı bu aşamada fark etmek kolaydır: listedeki her satırın karşısında bir çizim arayın.

3. Adım: Etkileşimli prototip ve kullanıcı testi

Tasarımcı onaylı wireframe'leri birbirine bağlar ve telefonunuzda açtığınız etkileşimli prototipi kurar. Butona dokunursunuz, sonraki ekran açılır. Ortada kod yoktur, ama deneyim gerçek uygulamaya çok yakındır.

Prototipin asıl değeri, gerçek kullanıcılarla test etme fırsatıdır. Nielsen Norman Group'un klasik araştırması, beş kullanıcıyla yaptığınız bir testin kullanım sorunlarının yaklaşık %85'ini ortaya çıkardığını gösterir. Aynı araştırma bütçeyi tek büyük teste harcamak yerine beşer kişilik üç küçük tura bölmeyi önerir: test edin, düzeltin, yeniden test edin.

Spor salonu örneğinde test şöyle işler: beş üyeyi tek tek davet edersiniz ve telefonu verip bir görev söylersiniz. "Yarın akşam 19.00'daki pilates dersine yer ayırın." Yardım etmezsiniz, yalnızca izlersiniz. Şunlara bakarsınız:

• Kullanıcı görevi tamamladı mı, kaç dokunuşta tamamladı?
• Nerede durakladı, hangi yanlış butona dokundu?
• Hangi kelimeyi anlamadı? "Seans" mı diyor, "ders" mi?

Beş kişiden üçü ders takvimini arayıp duruyorsa sorun kullanıcıda değil, navigasyondadır. Bu bulguyu prototipte düzeltmek bir günlük iştir.

Prototip başka kapılar da açar. Yatırımcıya veya yönetim kuruluna sunum yaparken çalışan bir maket, elli sayfalık dokümandan daha ikna edicidir. Geliştirme ekibi de neyi inşa edeceğini görerek efor tahminini netleştirir. Yazılım tamamlandıktan sonraki QA ve beta süreci ise ayrı bir iştir; onu mobil uygulama testi rehberimizde ele aldık.

4. Adım: Görsel tasarım ve tasarım sistemi

İskelet oturduktan sonra tasarımcı markanızı ekranlara giydirir: renk paleti, yazı tipi, ikon ailesi, boşluk düzeni, fotoğraf ve illüstrasyon dili. Bu adımda önce iki-üç anahtar ekran üzerinde yön çalışması görürsünüz. Yönü onayladığınızda tasarımcı aynı dili tüm ekranlara yayar.

Profesyonel ekipler ekranları tek tek boyamaz; önce bir tasarım sistemi kurar. Tasarımcı buton, form alanı, kart ve uyarı kutusu gibi bileşenleri bir kez tasarlar, her ekranda aynı bileşeni tekrar kullanır. Renkleri ve ölçüleri "design token" adı verilen değişkenlere bağlar. Marka renginiz değiştiğinde tek bir değeri güncellemek bütün ekranları günceller.

Bu yaklaşımın hız etkisini ölçen bir deney var. Figma'nın veri ekibinin yürüttüğü çalışma, tasarım sistemine erişimi olan tasarımcıların aynı görevi %34 daha hızlı tamamladığını gösterdi. Araştırmacılar bu oranın, sistemin göreve birebir uyduğu ideal koşulu yansıttığını ve üst sınır sayılması gerektiğini de not ediyor.

Görsel tasarımda güzellik kadar okunabilirlik de hesaba girer:

• Dokunma alanı: Apple iOS kontrolleri için 44x44 pt, Google ise Android için en az 48x48 dp öneriyor. Daha küçük butonlar yanlış dokunuş üretir.
• Kontrast: Açık gri zemin üzerine gri yazı şık durur, güneş altında okunmaz. WCAG ölçütleri normal metin için 4,5:1 kontrast ister. Konunun yasal boyutunu web erişilebilirliği rehberimizde işledik.
• Yazı boyutu: Kullanıcılar sistem ayarından yazıyı büyütür. Tasarım, büyüyen metinle bozulmamalıdır.
• Koyu tema: Sonradan eklemek zordur; renk değişkenlerini baştan iki temaya göre kurun.

Türkiye'ye özgü ayrıntıları da bu aşamada çözersiniz. Büyük harfe çevrilen metinlerde "i" harfinin "İ" olması gerekir; yanlış yapılandırılmış bir uygulama "GİRİŞ" yerine "GIRIŞ" yazar. Fiyatlar "1.250,00 TL", tarihler "19.09.2026" biçiminde görünmelidir. KVKK aydınlatma metni ve açık rıza onayı da kayıt akışının tasarlanmış birer ekranıdır; son anda eklenmiş bir pencere değil.

5. Adım: Developer teslimi (handoff)

Tasarım ile yazılım arasındaki köprü en çok burada çöker. Tasarımcı yalnızca "mutlu yol" ekranlarını bırakırsa geliştirici boşlukları kendi tahminiyle doldurur. Ortaya çıkan uygulama, onayladığınız tasarıma benzemez.

Eksiksiz bir teslim paketi şunları içerir:

• Tüm ekran durumları: Yükleniyor, boş liste, hata, başarı ve çevrimdışı görünümleri.
• Bileşen kuralları: Butonun pasif, basılı ve yükleniyor durumları; form alanının hata görünümü.
• Design token listesi: Renk, yazı boyutu, boşluk ve köşe yarıçapı değişkenleri.
• Görsel dosyalar: İkonlar vektör formatında, fotoğraflar farklı ekran yoğunluklarına göre dışa aktarılmış.
• Metin dokümanı: Ekranlardaki tüm yazılar, hata mesajları ve push metinleri.
• Animasyon notları: Geçişlerin süresi ve yönü.
• Uç durumlar: 40 karakterlik ad soyad, küçük ekranlı telefon, büyütülmüş yazı boyutu.

Figma bu işi Dev Mode ile kolaylaştırır. Geliştirici bir öğeye dokunduğunda ölçüleri, boşlukları ve bağlı değişkenleri görür. Figma'nın Dev Mode rehberine göre araç, seçili öğe için SwiftUI ve Jetpack Compose gibi platformlara uygun kod parçaları da üretir. Bu parçalar bitmiş kod değildir; geliştiriciye doğru ölçüyü veren bir başlangıç noktasıdır.

Teslim, dosyayı göndermekle bitmez. Sağlıklı bir süreçte tasarımcı ile geliştirici ekranları birlikte gözden geçirir, teknik olarak pahalı kalemleri konuşur. Geliştirme ilerledikçe tasarımcı çalışan sürümü tasarımla yan yana koyar ve farkları listeler. Tasarım QA adını verdiğimiz bu kontrol, yayın öncesi kalite turunun parçasıdır. Teklif toplarken bu kontrolün fiyata girip girmediğini sorun.

iOS ve Android tasarım farkları

İki platformun kullanıcıları farklı alışkanlıklarla gelir. Apple'ın Human Interface Guidelines (HIG) ve Google'ın Material Design 3 rehberleri bu alışkanlıkları tanımlar. 2025'te iki taraf da görsel dilini yeniledi: Apple iOS 26 ile Liquid Glass'ı, Google ise Material 3 Expressive'i duyurdu.

Bu farklar iki ayrı tasarım gerektiği anlamına gelmez. Flutter veya React Native ile geliştirdiğiniz projelerde tek bir tasarım dili kurarsınız; geri dönüş davranışı, tarih seçici ve izin pencereleri gibi ayrıntıları platforma uyarlarsınız. Böylece marka tutarlı durur, kullanıcı da kendi telefonunun alışkanlıklarını kaybetmez. Hangi platformla başlayacağınıza henüz karar vermediyseniz platform seçimi rehberimize göz atın.

Platformdan bağımsız bir gerçek daha var: başparmak. Steven Hoober'ın 1.333 gözleme dayanan saha çalışması, ekrana dokunan kullanıcıların %49'unun telefonu tek elle kullandığını saptadı. %36'sı telefonu bir eliyle kavrayıp diğer eliyle, %15'i ise iki başparmağıyla kullanıyordu. Ekranlar o günden bugüne büyüdü; üst köşelere ulaşmak daha da zorlaştı. Sık kullandığınız eylemleri ekranın alt yarısına yerleştirin, silme gibi geri dönüşü zor eylemleri başparmağın kolay ulaşmadığı bölgeye taşıyın.

Mobil uygulama tasarımı bütçede ne kadar yer tutar?

Business of Apps'in maliyet araştırmasına göre tasarım aşaması, bir mobil uygulama bütçesinin ortalama %20-25'ini oluşturur. Aynı derleme keşif aşamasına %10-15, geliştirmeye %40-55, teste %15-20 ve yayına %5-10 pay ayırır.

Bu payı, fiyat rehberimizde yayımladığımız 2026 Türkiye fiyat bantlarına uyguladığımızda şu planlama tablosu çıkar:

Tablodaki tutarlar bir piyasa istatistiği değil, oransal bir hesaptır; teklifinizi okurken kıyas noktası olarak kullanın. Süreler de toplam proje takvimini aynı oranla bölerek ulaştığımız planlama göstergeleridir. Kendi kapsamınız için hızlı bir tahmin isterseniz mobil uygulama maliyet hesaplayıcımızı deneyin.

Tasarım kalemini büyüten etkenler şunlardır:

• Benzersiz ekran sayısı: 20 ekranlı bir uygulama ile 60 ekranlı bir uygulamanın tasarım eforu aynı değildir.
• Kullanıcı rolü sayısı: Müşteri, kurye ve yönetici için ayrı arayüzler, üç ayrı uygulama tasarlamaya yaklaşır.
• Özel illüstrasyon ve animasyon: Markaya özel çizimler ve mikro etkileşimler ciddi işçilik ister.
• Araştırma derinliği: Saha görüşmeleri ve çok turlu kullanıcı testleri süreyi uzatır, ama riski düşürür.
• Platforma özel tasarım: iOS ve Android için tamamen ayrı arayüz istemek eforu neredeyse ikiye katlar.

Tasarruf etmenin doğru yolu tasarımı atlamak değil, kapsamı daraltmaktır. Hazır bir bileşen kitinden başlamak, ilk sürümü üç-beş kritik akışla sınırlamak ve illüstrasyonları ikinci faza bırakmak bütçeyi rahatlatır. "Tasarımı geliştirici halleder" yaklaşımı ise kısa vadede ucuz görünür; bedelini yeniden yazdığınız ekranlar ve kaybettiğiniz kullanıcılarla ödersiniz.

Figma ile süreç şeffaflığı: müşteri olarak neyi görürsünüz?

Tasarım araçlarında tartışma büyük ölçüde bitti. UX Tools'un 2.220 profesyonelle yaptığı 2024 tasarım araçları anketinde katılımcıların %82,3'ü ana arayüz tasarım aracı olarak Figma'yı gösterdi. Sizin için önemli olan pazar payı değil, bu aracın süreci ne kadar görünür kıldığıdır.

Figma tarayıcıda çalışır. Tasarımcının gönderdiği bağlantıyı açtığınızda program kurmadan dosyanın güncel durumunu görürsünüz. "Tasarımlar ne durumda?" sorusunun yanıtı bir PDF eki değil, her an açık bir penceredir.

Bu şeffaflık size dört somut imkân verir:

• Ekran üstünde yorum: Beğenmediğiniz butonun üzerine tıklar, notunuzu tam o noktaya bırakırsınız. "Üçüncü sayfadaki mavi şey" tarifleri biter.
• Telefonda prototip: Figma'nın mobil uygulamasıyla prototipi kendi telefonunuzda açar, gerçek boyutta denersiniz.
• Sürüm geçmişi: Bir önceki hafta onayladığınız tasarıma dönmek ve farkı görmek mümkündür.
• Tek doğruluk kaynağı: Geliştirici de aynı dosyadan çalışır; "hangi sürüm günceldi?" karmaşası yaşanmaz.

Şeffaflığın işe yaraması için geri bildirimi de düzenli vermeniz gerekir. Ekibinizdeki görüşleri tek bir kişide toplayın ve yorumları planlı turlarda iletin. Beş farklı kişiden beş farklı günde gelen çelişkili yorumlar, en iyi tasarım sürecini bile kilitler.

Sağlıklı bir tempoda tasarımcı haftada bir kısa sunum yapar: o hafta biten ekranları gösterir, açık soruları sorar, sonraki haftanın planını paylaşır. Siz de yorumlarınızı bir sonraki sunuma kadar dosyaya işlersiniz. Bu ritim, "üç hafta ses çıkmadı, sonra kırk ekran birden önümüze kondu" sürprizini ortadan kaldırır. Teklif aşamasında sunum sıklığını ve revizyon turu sayısını sorun; ikisi de sözleşmede yer almalıdır.

Son olarak mülkiyet konusu. Proje bittiğinde Figma dosyalarının sizin hesabınıza devrini isteyin ve bunu sözleşmeye yazdırın. Kaynak dosya, ileride başka bir ekiple çalışsanız bile uygulamanızı geliştirmeye devam etmenizi sağlar. Yalnızca PNG veya PDF çıktısı teslim alan işletme, ilk büyük revizyonda tasarımı baştan çizdirir.

Yapay zeka ile mobil uygulama tasarımı: nerede işe yarar?

Google'ın arama önerilerinde "mobil uygulama tasarımı yapan yapay zeka" sorgusu üst sıralarda çıkıyor. Merak haklı: metinden ekran üreten araçlar birkaç dakikada derli toplu görünen arayüzler çıkarıyor.

Profesyonellerin deneyimi ise daha temkinli bir tablo çiziyor. Figma'nın 2.500 tasarımcı ve geliştiriciyle yaptığı 2025 yapay zeka araştırmasında geliştiricilerin %59'u yapay zekayı asıl işinde kullandığını söylerken, tasarımcılarda bu oran %31. Katılımcıların %78'i yapay zekanın verimliliği artırdığını kabul ediyor; ancak çıktıya güvendiğini söyleyenlerin oranı yalnızca %32.

Yapay zeka şu işlerde gerçekten hız kazandırır:

• İlk fikir turunda farklı yerleşim alternatifleri üretmek.
• Wireframe'ler için gerçekçi örnek metin ve içerik yazmak.
• Yer tutucu görsel ve ikon taslağı hazırlamak.
• Kullanıcı testi notlarını özetlemek ve ortak temaları çıkarmak.

Şu işlerde ise hâlâ insan kararı gerekir:

• İşinize özgü akış mantığı. Araç, üyeliğini donduran bir üyenin ders ayırıp ayıramayacağını bilmez.
• Yüzlerce ekran boyunca tutarlılık ve tasarım sistemi disiplini.
• Platform kuralları, dokunma alanları ve kontrast gibi erişim ölçütleri.
• Boş, hatalı ve çevrimdışı ekran durumları. Üretilen ekranlar neredeyse her zaman mutlu yolu gösterir.
• Markanızı rakipten ayıran özgün görsel dil.

Canva gibi genel amaçlı araçlarla sunumluk ekran görselleri hazırlamak da mümkün. Ancak bileşen kütüphanesi, değişkenler ve developer teslimi gerektiren gerçek bir projede ürün tasarımı araçlarına ihtiyaç duyarsınız. Yapay zeka araçlarıyla uygulama üretmenin sınırlarını yapay zekaya uygulama yaptırmak yazımızda karşılaştırmalı olarak inceledik.

Tasarım aşamasında sık yapılan 7 hata

1. Wireframe'i atlayıp renkli ekranla başlamak. Tartışma renge kayar, akış sorunları kodlama aşamasına taşınır.
2. Yalnızca mutlu yolu tasarlamak. Boş liste, hata ve çevrimdışı durumları çizilmemiş bir tasarım yarım tasarımdır.
3. Web sitesini küçültüp uygulama saymak. Kullanıcıya site dışında bir değer sunmayan uygulama ne mağaza incelemesinde ne de telefonda yer bulur.
4. İzinleri ilk açılışta istemek. Kullanıcı faydayı görmeden karşısına çıkan push ve konum izni çoğunlukla "Hayır" yanıtı toplar. İzni, değerini anlattığınız anda isteyin; yöntemi push stratejisi rehberimizde anlattık.
5. Gerçek Türkçe metinle denememek. Uzun kelimeler butonlardan taşar, büyük "İ" harfi bozuk çıkar.
6. Dokunma alanı ve kontrastı ihmal etmek. Küçük butonlar ve soluk yazılar, yaşı ilerlemiş kullanıcıları ve güneş altında telefona bakan herkesi zorlar.
7. Tasarım QA yapmamak ve kaynak dosyayı istememek. Yayına çıkan sürüm tasarımdan sapar; dosyalar ajansta durduğunda her revizyon size bağımlılık olarak döner.

Yayın sonrası da tasarım bitmez. Hangi ekranda kullanıcı kaybettiğinizi ölçmeden yaptığınız her değişiklik tahmindir. İzlemeniz gereken metrikleri mobil uygulama analitiği rehberimizde anlattık.

Sıkça Sorulan Sorular

Mobil uygulama tasarımı ne kadar sürer?

Basit bir uygulamanın tasarımı genellikle 2-3 hafta, orta ölçekli bir uygulamanınki 3-5 hafta, e-ticaret ve kurumsal projelerinki 4-8 hafta sürer. Süreyi en çok ekran sayısı, kullanıcı rolü sayısı ve geri bildirim turlarının hızı etkiler.

Tasarım, toplam uygulama maliyetinin yüzde kaçını oluşturur?

Business of Apps'in derlediği verilere göre tasarım aşaması toplam bütçenin ortalama %20-25'ini oluşturur. 300.000 TL'lik bir projede bu, 60.000-75.000 TL'lik bir tasarım kalemi demektir.

Wireframe ile prototip arasındaki fark nedir?

Wireframe, tek bir ekranın renksiz iskeletidir ve yerleşim kararlarını gösterir. Prototip ise ekranların birbirine bağlandığı, telefonda dokunarak gezdiğiniz etkileşimli makettir; akışı gerçek kullanıcılarla test etmenizi sağlar.

Figma dosyalarının sahibi kimdir?

Sahiplik sözleşmeye bağlıdır; bu yüzden kaynak dosyaların proje sonunda hesabınıza devrini sözleşmeye yazdırın. Kaynak dosya, ileride farklı bir ekiple çalışsanız bile tasarımı sıfırdan çizdirmeden devam etmenizi sağlar.

iOS ve Android için ayrı tasarım gerekir mi?

Çoğu projede gerekmez. Tek bir tasarım dili kurup geri dönüş davranışı, tarih seçici ve izin pencereleri gibi ayrıntıları platforma uyarlamak hem marka tutarlılığını korur hem tasarım eforunu makul düzeyde tutar.

Yapay zeka ile mobil uygulama tasarımı yapmak mümkün mü?

Yapay zeka araçları ilk taslakları ve alternatif yerleşimleri dakikalar içinde üretir, ancak işinize özgü akış mantığını, hata durumlarını ve platform kurallarını kendiliğinden çözmez. Figma'nın 2025 araştırmasında katılımcıların yalnızca %32'si yapay zeka çıktısına güvendiğini söylüyor.

Tasarımı onayladıktan sonra değişiklik istemek mümkün mü?

Mümkün, ancak maliyeti aşamaya göre değişir. Wireframe aşamasındaki değişiklik dakikalar, görsel tasarımdaki değişiklik saatler, kodlanmış ekrandaki değişiklik ise günler ister; bu yüzden büyük kararları erken aşamada verin.

Hazır UI kit kullanmak tasarım kalitesini düşürür mü?

Düşürmez; iyi bir UI kit, test edilmiş bileşenlerle sağlam bir başlangıç sunar ve bütçeyi rahatlatır. Kaliteyi asıl etkileyen, kitin markanıza ve akışlarınıza ne kadar özenle uyarlandığıdır.

Mobil uygulama tasarımı, projenin süs katmanı değil, en ucuz risk azaltma aracıdır. Akışları wireframe'de, kullanım sorunlarını prototipte, tutarlılığı tasarım sisteminde çözen bir ekip, geliştirme aşamasına sürprizsiz girer. Siz de her adımda neyi onayladığınızı bildiğinizde süreç kara kutu görüntüsünden çıkar.

Mobil uygulama geliştirme projelerimizde tasarımı Figma üzerinden, her aşamasını izlediğiniz şeffaf bir süreçle yürütüyoruz. Uygulama fikrinizi ekranlara dökmek için bizimle iletişime geçin.