Kısa cevap: Mobil uygulama; hedefi ve kullanıcıyı netleştirmek, rakipleri incelemek, akışları ve ekran listesini çıkarmak, wireframe çizmek, tasarım sistemini ve arayüzü kurmak, prototiple test etmek, geliştiriciye eksiksiz teslim etmek, mağazaya hazırlamak ve yayından sonra ölçerek iyileştirmek adımlarıyla tasarlanır.
Ben Selçuk Aker; İstanbul merkezli, 19 yılı aşkın deneyime sahip bir grafik ve UI/UX tasarımcıyım ve uzaktan çalışıyorum. Uygulama fikri olan kişilerin çoğu doğrudan "ekranları çizelim" diye başlamak ister. Oysa ekrana geçmeden önce verilmesi gereken kararlar atlandığında, tasarım ya kodlama sırasında ya da yayından sonra yeniden yapılır. Bu rehberde bir mobil uygulamanın fikirden yayına ve yayın sonrasına kadar hangi adımlarla tasarlandığını, her adımda hangi dosyanın ortaya çıktığını anlatıyorum. Mobil tasarımın genel çerçevesi için önce mobil uygulama tasarımı nedir rehberini okumak isteyebilirsiniz.
Adımlar ve teslimler: genel bakış
Aşağıdaki tablo, rehberdeki on adımı ve her adımın sonunda elinizde olması gereken çıktıyı özetliyor. Küçük bir projede bazı adımlar kısalabilir; ama hiçbiri tamamen atlanmamalıdır.
| # | Adım | Ana soru | Teslim / çıktı |
|---|---|---|---|
| 1 | Fikir ve hedef | Hangi problemi, kimin için çözüyoruz? | Tek sayfalık ürün özeti, başarı ölçütü |
| 2 | Kullanıcı ve rakip | Kullanıcı bugün ne yapıyor, rakipler nasıl çözüyor? | Görüşme notları, rakip akış incelemesi |
| 3 | Akışlar ve ekran envanteri | Kullanıcı hangi adımlardan geçecek? | Kullanıcı akışları, ekran ve durum listesi |
| 4 | Wireframe | Her ekranda ne var, öncelik ne? | Düşük ayrıntılı wireframe seti |
| 5 | Tasarım sistemi | Görsel dilin kuralları neler? | Renk, tipografi, aralık, bileşen kütüphanesi |
| 6 | Görsel arayüz | Ekranlar son halinde nasıl görünüyor? | Tüm ekranlar ve durumlar |
| 7 | Prototip ve test | Kullanıcı görevi tamamlayabiliyor mu? | Tıklanabilir prototip, test bulguları |
| 8 | Geliştirici teslimi | Geliştirici neyi, nasıl kodlayacak? | Devir dosyası, varlıklar, davranış notları |
| 9 | Mağaza hazırlığı | Mağaza sayfası uygulamayı anlatıyor mu? | Uygulama ikonu, mağaza görselleri |
| 10 | Yayın sonrası iterasyon | Ne çalışıyor, ne çalışmıyor? | Ölçüm raporu, iyileştirme listesi |
Adım 1: Fikir, hedef ve tek kritik görev
İlk adım, uygulamanın hangi problemi çözdüğünü tek cümleyle yazmaktır. "Herkes için her şeyi yapan uygulama" tasarlanamaz. Şu soruların cevabı bir sayfayı geçmemelidir:
- Uygulamayı kim kullanacak ve hangi durumda açacak?
- Kullanıcının uygulamada yapacağı en önemli tek görev nedir?
- Bu görevi bugün hangi yolla yapıyor?
- İlk sürüm başarılı olursa bunu hangi göstergeyle anlayacağız?
Bu aşamada özellik listesi yerine görev listesi yazmak önemlidir. "Mesajlaşma özelliği" bir özelliktir; "kurye, teslimat adresini bulamadığında müşteriye hızlıca ulaşır" bir görevdir. Görevler, ilk sürümün (MVP) sınırını çizmeyi kolaylaştırır. Bu sınırın nasıl çizileceğini startup UI/UX tasarımcısı ve MVP kapsamı yazısında anlattım.
Adım 2: Kullanıcıyı ve rakipleri tanımak
Bu adımın amacı varsayımları sınamaktır. Hedef kullanıcılardan birkaçıyla yapılan kısa görüşmeler, bugün işi nasıl yaptıklarını ve nerede zorlandıklarını gösterir. Görüşmede fikri satmaya değil, mevcut davranışı anlamaya odaklanın.
Rakip incelemesi ise ekran görüntüsü toplamak değildir. Rakip uygulamaları indirip aynı görevi baştan sona denemek, hangi adımların alışkanlık haline geldiğini ve hangilerinin kullanıcıyı yorduğunu gösterir. Mağaza yorumları da kullanıcıların şikâyet ettiği noktalar için iyi bir kaynaktır.
Araştırma yöntemlerinin hangi soruya cevap verdiğini kullanıcı deneyimi tasarımı nedir rehberinde ayrıntılı açıkladım.
Adım 3: Kullanıcı akışları ve ekran envanteri
Akış, kullanıcının bir görevi tamamlarken geçtiği ekranların ve karar noktalarının şemasıdır. Örneğin "randevu alma" akışı: hizmet seçimi, tarih ve saat seçimi, bilgi girişi, onay ve hatırlatma. Her karar noktasında "ya şu olursa?" sorusu sorulur: seçilen saat dolmuşsa, kullanıcı giriş yapmamışsa, ödeme başarısız olursa.
Akışlardan ekran envanteri çıkar. Bu liste yalnız ana ekranları değil, durumları da içermelidir:
- Boş durum (henüz kayıt yokken)
- Yükleme durumu
- Hata durumu (bağlantı yok, sunucu hatası, geçersiz giriş)
- İzin istekleri ve izin reddedildiğinde görülen ekran
- Başarı ve onay ekranları
Durumların tam listesini ekran listesine eklenmesi gereken durumlar yazısında verdim. Bu adım, fiyat ve süre tahmininin de temelidir; ekran ve durum sayısı bilinmeden yapılan tahminler genellikle eksik kalır.
Adım 4: Wireframe ile yerleşim
Wireframe, renk ve görselden arındırılmış, her ekranda neyin olacağını ve önceliğini gösteren taslaktır. Bu aşamada tartışılacak konu "güzel mi?" değil, "doğru bilgi doğru sırada mı?" sorusudur.
Wireframe'de dikkat edilecekler:
- Gerçek ya da gerçeğe yakın içerik kullanın. Türkçe metinler İngilizceden uzundur ve lorem ipsum bunu gizler.
- Birincil eylemin yerini netleştirin; tek elle ulaşılabilir alanı düşünün.
- Gezinme yapısını (alt sekme, üst menü, yığın) bu aşamada sabitleyin.
Wireframe atlanırsa yapısal kararlar görsel tasarım sırasında verilir; her değişiklik çok daha pahalıya gelir. Wireframe'de hangi kararların test edileceği için wireframe ve prototip kararları yazısına bakabilirsiniz.
Adım 5: Tasarım sistemi
Görsel arayüze geçmeden önce temel kuralları kurmak, ekran sayısı arttıkça tutarlılığı korur. Bir mobil uygulama için asgari tasarım sistemi şunları içerir:
- Renk: Ana renk, ikincil renkler, anlamsal renkler (başarı, uyarı, hata), açık ve gerekiyorsa koyu tema karşılıkları.
- Tipografi: Başlık, gövde, etiket ölçüleri; dinamik yazı boyutuna uyum.
- Aralık ve ızgara: Tutarlı bir aralık ölçeği.
- Bileşenler: Buton, giriş alanı, liste öğesi, kart, sekme çubuğu, diyalog; her birinin durumlarıyla birlikte.
- İkonlar: Tek bir stil ve ölçü kuralı.
Bu aşamada platform kılavuzları, Apple'ın Human Interface Guidelines ve Google'ın Material Design 3 dokümanları başvuru kaynağıdır. Bileşenlerin yanında hangi notların teslim edilmesi gerektiğini design system teslimi yazısında anlattım.
Adım 6: Görsel arayüz
Tasarım sistemi hazır olduğunda ekranlar bu bileşenlerle kurulur. Bu aşamada marka kimliği arayüze yansır: renk, illüstrasyon dili, fotoğraf kullanımı ve mikro etkileşimler.
Kontrol edilmesi gerekenler:
- Her ekranda tek bir birincil eylem ve açık bir görsel hiyerarşi var mı?
- Metin kontrastı WCAG 2.2 AA düzeyinde normal metin için en az 4.5:1 mi?
- Dokunma alanları platform önerilerine (Apple 44 × 44 pt, Android 48 × 48 dp) uygun mu?
- En küçük ve en büyük ekran boyutunda düzen bozuluyor mu?
- Tüm durumlar (boş, yükleme, hata, izin) görsel olarak tamamlandı mı?
Ekran tasarımında uygulanacak genel kurallar UI/UX tasarım ilkeleri rehberinde yer alıyor.
Adım 7: Prototip ve kullanılabilirlik testi
Ekranlar birbirine bağlanarak tıklanabilir bir prototip kurulur. Prototip, uygulama kodlanmadan önce akışın gerçek kullanıcılarla denenmesini sağlar.
Basit bir test planı:
- En kritik iki ya da üç görevi seçin.
- Hedef kullanıcıya benzeyen birkaç kişiyle tek tek oturum yapın.
- Görevi verin, yardım etmeden izleyin, düşüncelerini sesli söylemelerini isteyin.
- Takıldıkları yerleri ve tekrar eden sorunları not edin.
- Düzeltin ve gerekirse küçük bir tur daha yapın.
Yatırımcıya ya da paydaşa gösterilecek prototiplerin nasıl hazırlanacağı için yatırımcıya sunulacak ürün prototipi yazısına bakabilirsiniz. Prototip için kullanılan araçları UI/UX tasarım programları rehberinde karşılaştırdım.
Adım 8: Geliştirici teslimi
Tasarım dosyası geliştiriciye yalnız ekran görüntüsü olarak teslim edilirse, eksik kalan her konu kodlama sırasında tahminle doldurulur. Eksiksiz bir devir paketi şunları içerir:
- Tüm ekranlar ve durumlar, akış sırasıyla düzenlenmiş halde.
- Bileşen kütüphanesi ve her bileşenin durumları.
- Renk, tipografi ve aralık değerleri (mümkünse token olarak).
- İkon ve görsellerin uygun biçimde dışa aktarılmış hali.
- Geçiş ve animasyon notları (süre, tetikleyici).
- Hata mesajları ve tüm arayüz metinleri.
- Karar kaydı: neden bu çözüm seçildi, hangi alternatif elendi.
Devir, geliştirici wireframe aşamasından itibaren sürece dahil olduğunda çok daha sorunsuz geçer. Teknik kısıtlar erken öğrenilirse sonradan değişiklik azalır. Ayrıntılar için freelance mobil uygulama tasarımcısı ve geliştirici devri, mobil uygulama geliştiricileri için UI/UX iş birliği ve ekrandan geliştirici devrine yazılarına bakabilirsiniz.
Adım 9: Mağaza hazırlığı
Mağaza sayfası, kullanıcının uygulamayı indirmeden önce gördüğü tek yerdir. Hazırlanması gerekenler:
- Küçük boyutta da tanınan bir uygulama ikonu.
- Uygulamanın ne işe yaradığını ilk karelerde anlatan ekran görüntüleri.
- Kısa ve açık bir tanıtım metni.
- Gizlilik ve veri kullanımı bilgileri (mağazaların istediği beyanlar).
Mağaza görselleri genellikle arayüz tasarımından ayrı bir teslim olarak planlanır. Ölçüler ve kurallar Apple ve Google tarafından belirlenir ve değişebilir; güncel bilgiyi App Store Connect ve Google Play Console yardım sayfalarından kontrol edin. Uygulamanın kodlanması, mağaza hesabı ve yayın süreci ise geliştirme ekibinin sorumluluğundadır.
Adım 10: Yayından sonra ölçüm ve iterasyon
Yayın, tasarımın sonu değil, gerçek verinin başlangıcıdır. İlk haftalarda şunlara bakılır:
- Kritik görevin tamamlanma oranı ve akışın hangi adımında terk edildiği.
- Destek taleplerinde ve mağaza yorumlarında tekrar eden şikâyetler.
- Çökme ve hata raporlarının hangi ekranlarda yoğunlaştığı.
Bu veriler bir iyileştirme listesine dönüşür ve sorunlar etki ile düzeltme maliyetine göre sıralanır. Bir sonraki sürüm bu listeden planlanır. Ölçümün işe yaraması için hangi olayların kaydedileceği tasarım aşamasında belirlenmelidir.
Sürüm planında her değişikliğin hangi soruna cevap verdiği yazılmalıdır. Yeni bir özellik eklemek ile mevcut bir akıştaki engeli kaldırmak arasında seçim yapılırken, ikincisi çoğu zaman daha az maliyetle daha fazla kullanıcıya dokunur. Tasarım dosyası da her sürümle güncellenmeli; yayındaki uygulama ile tasarım dosyası birbirinden uzaklaşırsa bir sonraki geliştirme turu eski ve yanlış ekranlar üzerine kurulabilir.
Örnek: bir randevu uygulamasında on adım
Adımları somutlaştırmak için kurgusal bir örnek düşünelim: küçük kliniklerin hastalarına randevu aldırdığı bir uygulama. İlk adımda tek kritik görev "hasta, uygun bir saate üç dakikadan kısa sürede randevu alır" diye yazılır. Kullanıcı görüşmelerinde hastaların çoğunun telefonla aradığı ve en çok "hangi doktor müsait?" sorusunu sorduğu öğrenilir. Rakip uygulamalar denenir; bazılarında kayıt olmadan takvimin görülemediği fark edilir.
Akış aşamasında doktor seçimi, tarih ve saat, hasta bilgisi ve onay adımları çıkar; "seçilen saat bu sırada başkası tarafından alındıysa" durumu ayrıca listelenir. Wireframe'de takvim görünümü ile liste görünümü karşılaştırılır. Tasarım sisteminde sağlık alanına uygun, sakin bir renk paleti ve büyük dokunma alanları tanımlanır. Prototip testinde yaşlı katılımcıların küçük saat kutucuklarında zorlandığı görülürse kutucuklar büyütülür. Devirde randevu çakışması ve bağlantı kopması durumları ayrıca belgelenir; mağaza görsellerinde ilk kare randevu alma ekranını gösterir. Yayından sonra randevu akışının tamamlanma oranı izlenir.
Bu örnek, adımların birbirini nasıl beslediğini göstermek için kurgulanmıştır; gerçek bir müşteri projesini anlatmaz.
Sürece kimler dahil olur?
Bir mobil uygulama projesinde tasarımcı tek başına çalışmaz. Tipik bir ekipte şu roller bulunur ve küçük ekiplerde birkaçı aynı kişide birleşebilir:
- Ürün sahibi ya da ürün yöneticisi: Hedefi, önceliği ve kapsamı belirler, kararları onaylar.
- UI/UX tasarımcı: Akış, wireframe, tasarım sistemi, arayüz ve prototipi hazırlar.
- Mobil geliştirici: Uygulamayı iOS ve Android için kodlar, teknik kısıtları paylaşır.
- Arka uç geliştirici: Veri, sunucu ve API tarafını kurar; hata ve çevrimdışı durumları birlikte tanımlar.
- Test uzmanı: Yayın öncesinde işlevsel ve görsel hataları yakalar.
- İçerik sorumlusu: Arayüz metinlerini, bildirimleri ve mağaza tanıtım metnini hazırlar.
Rollerin baştan belirlenmesi, "bunu kim karar verecek?" sorusunun proje ortasında sorulmasını önler.
Sık yapılan hatalar
- İlk sürüme her özelliği sığdırmaya çalışmak.
- Wireframe'i atlayıp doğrudan görsel tasarıma geçmek.
- Yalnız "her şey yolunda" ekranlarını tasarlayıp durumları unutmak.
- Geliştiriciyi tasarım bitince sürece dahil etmek.
- Test etmeden "kullanıcı bunu anlar" diye varsaymak.
- Mağaza görsellerini son güne bırakmak.
Erken aşamadaki ekiplerin sık düştüğü diğer hataları erken aşama startup tasarım hataları yazısında topladım. Yapay zekâ araçlarıyla hızlı uygulama üretiminin nerede işe yarayıp nerede risk yarattığını ise yapay zekâ ile uygulama yapılır mı rehberinde anlattım.
Kendi tasarım akışım
Mobil uygulama projelerinde genellikle ürün özeti ve görev listesiyle başlıyor, akış ve ekran envanterini çıkardıktan sonra wireframe, tasarım sistemi ve arayüz aşamalarına geçiyorum. Ekranları ve prototipi Figma'da hazırlıyor, geliştiriciye durumları ve davranış notlarını içeren bir devir dosyası teslim ediyorum. Uzaktan çalıştığım için düzenli kısa görüşmeler ve paylaşılan dosya üzerindeki yorumlar sürecin temelini oluşturuyor.
Sorumluluk sınırını baştan açık yazıyorum: benim işim tasarım; uygulamanın kodlanması, sunucu altyapısı ve mağazada yayına alınması geliştirme ekibinin sorumluluğundadır. Portfolyomda yayımlanan mobil uygulama arayüzlerini mobil uygulama çalışmaları sayfasında görebilirsiniz; rolü teyit edilmiş projelerden Danone ve ERP Software'de arayüz tasarımını üstlendim. Startup'lar için kapsamı startup tasarım desteği, uygulama projeleri için mobil uygulama tasarımı hizmeti sayfasında anlattım; projenizi konuşmak için iletişim sayfasını kullanabilirsiniz. Alanın tamamı için UI/UX tasarım ana sayfasına, tasarımcının görevleri için UI/UX tasarımcı ne iş yapar rehberine bakabilirsiniz.
Özet ve kontrol listesi
- Ürün özeti tek sayfa mı ve tek kritik görev yazılı mı?
- Kullanıcılarla en az birkaç kısa görüşme yapıldı mı, rakip akışlar denendi mi?
- Akışlar ve ekran envanteri durumlarla birlikte çıkarıldı mı?
- Wireframe gerçek içerikle hazırlandı mı?
- Tasarım sistemi, bileşenler ve durumları tanımlandı mı?
- Kontrast, dokunma alanı ve ekran boyutu kontrolleri yapıldı mı?
- Prototip gerçek kullanıcılarla test edildi mi?
- Devir paketi ekranlar, durumlar, token'lar, varlıklar ve metinleri içeriyor mu?
- Mağaza ikonu ve görselleri ayrı teslim olarak planlandı mı?
- Yayın sonrası hangi göstergenin izleneceği belirlendi mi?
Mobil uygulama tasarım süreci hakkında sık sorulan sorular
Uygulama tasarımına nereden başlanmalı?
Ekranlardan değil, problemden başlanmalı. Uygulamanın kimin için hangi problemi çözdüğünü, kullanıcının en önemli görevini ve ilk sürümün başarısının nasıl ölçüleceğini tek sayfada yazmak, sonraki bütün kararları kolaylaştırır.
Kod bilmeden uygulama tasarlanabilir mi?
Evet. Uygulama tasarımı akış, wireframe, arayüz ve prototip üretmeyi kapsar ve kod yazmayı gerektirmez. Yine de platform kurallarını, bileşenlerin nasıl kodlandığını ve teknik kısıtları anlamak, geliştiriciyle çalışmayı kolaylaştırır.
Bir uygulamanın tasarımı ne kadar sürer?
Ekran ve durum sayısına, kullanıcı rolü sayısına, araştırma ve test kapsamına ve karar alma hızına göre değişir. Tek rollü, birkaç akıştan oluşan bir ilk sürüm ile çok rollü bir platform aynı sürede tasarlanmaz. Gerçekçi bir süre, akışlar ve ekran envanteri çıkarıldıktan sonra verilebilir.
Figma prototipi yayınlanabilir bir uygulama mıdır?
Hayır. Figma prototipi ekranların birbirine bağlandığı bir modeldir; veri kaydetmez, sunucuyla konuşmaz ve mağazaya yüklenemez. Uygulamanın kodlanması ayrı bir geliştirme sürecidir. Prototip, bu süreç başlamadan önce akışı test etmek ve ekibi aynı noktada buluşturmak için kullanılır.
Wireframe atlanabilir mi?
Çok küçük ve tanıdık bir akışta kısaltılabilir, ama tamamen atlamak genellikle pahalıya gelir. Wireframe olmadan yapısal kararlar görsel tasarım sırasında verilir ve her değişiklik, renk, görsel ve bileşenlerin de yeniden düzenlenmesini gerektirir.
İlk sürümde kaç ekran olmalı?
Sabit bir sayı yoktur. İlk sürüm, kritik görevi baştan sona tamamlatan en küçük ekran setinden ve bu ekranların durumlarından oluşmalıdır. Ekran sayısını belirleyen şey özellik listesi değil, ilk sürümde desteklenecek görevlerdir.
Tasarımcı ile geliştirici ne zaman birlikte çalışmaya başlamalı?
İdeali, akış ve wireframe aşamasıdır. Geliştirici bu aşamada teknik kısıtları, hazır bileşenleri ve maliyetli çözümleri erkenden belirtebilir. Tasarım bittikten sonra başlayan iş birliği, kodlama sırasında değişikliklerin artmasına yol açar.
Uygulama fikrimi tasarımcıya nasıl anlatmalıyım?
Kısa bir özet hazırlayın: uygulama kimin için, hangi problemi çözüyor, kullanıcının en önemli görevi ne, beğendiğiniz ya da rakip gördüğünüz uygulamalar hangileri, hangi platformlar hedefleniyor ve geliştirme ekibi belli mi? Özellik listesi yerine görevleri anlatmak, kapsamın doğru tahmin edilmesini kolaylaştırır.
Yapay zekâ ile uygulama tasarlanabilir mi?
Yapay zekâ araçları hızlı ekran taslakları, varyasyonlar ve metin önerileri üretmede yardımcı olabilir. Ancak hangi görevin öncelikli olduğu, akışın nerede kullanıcıyı yorduğu, durumların eksiksiz tasarlanıp tasarlanmadığı ve tasarım sisteminin tutarlılığı insan kararı gerektirir. Ayrıntısını yapay zekâ ile uygulama yapılır mı rehberinde anlattım.