UI/UX Nedir? UI ile UX Farkı, Tasarım Süreci ve Teslim Edilenler

UI/UX, bir dijital ürünün iki katmanını birlikte anlatan kısaltmadır. UX (User Experience, kullanıcı deneyimi), kullanıcının bir işi baştan sona nasıl yaptığıdır: kaç adımda bittiği, nerede takıldığı, hata yapınca ne olduğu ve sonunda işini halledip halletmediği. UI (User Interface, kullanıcı arayüzü) ise o işi yaparken dokunduğu her şeydir: butonlar, form alanları, tipografi, renkler, ikonlar ve bunların basılı, seçili, devre dışı ya da hatalı durumları. UI/UX tasarım, bu iki katmanı aynı hedefe göre kurma işidir.

Ayrımı tek cümleye indirelim. UX “doğru şeyi, doğru sırayla mı yaptırıyoruz?” sorusuna, UI “bu adım ekranda anlaşılır ve kullanılır görünüyor mu?” sorusuna cevap verir. UX, UI’ı kapsar: iyi bir arayüz kötü kurgulanmış bir akışı kurtaramaz, ama kötü bir arayüz iyi kurgulanmış bir akışı rahatlıkla bozabilir.

Bu yazıyı tasarımcı olmak isteyenler için değil, tasarım yaptıracak kişiler için yazdım. VP Engineering olarak işim, tasarımın koda dönüştüğü yerde durmak; projelerin en pahalı hatalarını yıllardır tam o geçişte görüyorum. Aşağıdaki sahnede bir ödeme ekranının iskeleti (UX) ile görsel katmanı (UI) ayrı ayrı görünüyor.

Pratikte iki katman aynı dosyada, aynı ekipte ve çoğu zaman aynı kişinin elinde ilerler. Ayrımı bilmenin faydası, bir şikâyet geldiğinde çözümü doğru yerde aramaktır. “Kullanıcılar faturayı bulamıyor” sorununu buton rengini değiştirerek çözemezsiniz. “Metin okunmuyor” sorununu da menüyü baştan kurarak çözemezsiniz.

Bir de terim karmaşasına değinelim. İlanlarda “ürün tasarımcısı”, “UX designer”, “UI designer”, “arayüz tasarımcısı” gibi unvanlar birbirinin yerine kullanılır. İşi yaptıran taraf için unvan önemli değil; önemli olan teklifte hangi aşamaların yazılı olduğu. Aşağıdaki süreç bölümü bu yüzden unvanlar yerine çıktılar üzerinden ilerliyor.

Fark, aynı ekrana iki farklı soru setiyle bakınca netleşir. Bir mobil bankacılık uygulamasındaki para transferi onay ekranını düşünün. UX tarafı şunu sorar: kullanıcı alıcıyı ve tutarı bu ekranda son kez kontrol edebiliyor mu, yanlış IBAN girdiyse geri dönüş yolu var mı, onaydan sonra ne olacağını biliyor mu? UI tarafı şunu sorar: tutar ekrandaki en baskın öğe mi, “Onayla” butonu yeterince büyük ve “İptal”den yeterince uzak mı, hata mesajı yalnız kırmızı renkle değil ikon ve metinle de anlatılıyor mu?

İki soru seti de aynı ekranı değiştirir, ama farklı sorunları yakalar. Aşağıdaki tablo bu ayrımı tasarım ekibiyle konuşurken kullanabileceğiniz dile çeviriyor.

Türkiye’den üç tanıdık ekran

“Güzel ama kullanılmıyor” ile “eski görünüyor ama işliyor” ayrımı da buradan çıkar. Pek çok kurumsal panel eski görünür ama ekip yıllardır o ekranla işini dakikalar içinde bitirir; böyle bir sistemi yalnız güzelleştirmek için baştan tasarlamak, alışkanlıkları bozup verimi düşürebilir. Tersi de sık olur: lansmanı yeni yapılmış, çok şık bir mobil uygulama, kayıt akışı fazla uzun olduğu için ilk haftalarda kullanıcı kaybeder. İlkinin ihtiyacı dikkatli bir UI yenilemesidir, ikincisinin UX düzeltmesi.

Ajanstan ajansa adlar değişir, ama oturmuş bir UX tasarım süreci aşağı yukarı aynı sekiz aşamadan geçer. Double Diamond ya da Design Thinking gibi çerçeveler bunları farklı başlıklar altında toplar. Altta yatan fikir aynı: problemi anlamadan çözüm çizmeyin, çözümü de önce kâğıt ve gri kutu gibi ucuz malzemeyle deneyin. Kod en pahalı malzemedir ve en sona kalır.

Sıra önemlidir, ama sürecin düz bir çizgi olmadığını baştan kabul edin. Prototip testinde çıkan bir bulgu sizi wireframe’e, bazen bilgi mimarisine geri gönderir. Bu geri dönüş başarısızlık sayılmaz. Asıl başarısızlık, aynı bulguyu ürün canlıya çıktıktan sonra destek taleplerinden öğrenmektir.

1. 1KeşifÖrnek: 0,5 hafta
   Problemi, iş hedefini ve kapsamı netleştirmek.

   Girdi

   İş hedefleri, mevcut ürün veya fikir, rakipler, bütçe, takvim ve teknoloji kısıtları.

   Çıktı

   Problem tanımı, başarı ölçütleri, kapsam ve varsayım listesi.

   Kim katılır?

   Ürün sahibi, karar verici, tasarım lideri, teknik lider.

2. 2Kullanıcı araştırmasıÖrnek: 1–3,5 hafta
   Varsayımları gerçek kullanıcı davranışıyla sınamak.

   Girdi

   Ulaşılabilir kullanıcılar, analitik verisi, destek kayıtları, satış ekibinin notları.

   Çıktı

   Araştırma raporu, persona veya iş tanımları, öncelikli sorun listesi.

   Kim katılır?

   UX araştırmacısı veya tasarımcı, ürün sahibi; görüşmelerde genellikle 5–8 kullanıcı.

3. 3Bilgi mimarisi ve akışÖrnek: 0,5–3,5 hafta
   İçeriği kullanıcının zihnindeki gruplara göre dizmek, görev adımlarını kısaltmak.

   Girdi

   Araştırma bulguları, içerik envanteri, iş kuralları, rol ve yetki listesi.

   Çıktı

   Site haritası veya navigasyon yapısı, görev akışları, ekran listesi.

   Kim katılır?

   UX tasarımcı, ürün sahibi, gerekirse içerik sorumlusu.

4. 4WireframeÖrnek: 1–4,5 hafta
   Ekranın yapısını renk ve süsten bağımsız kurmak.

   Girdi

   Onaylı akışlar, ekran listesi, gerçek içerik taslağı.

   Çıktı

   Düşük ve orta çözünürlüklü wireframe seti, ilk tıklanabilir taslak.

   Kim katılır?

   UX tasarımcı; teknik lider uygulanabilirlik açısından gözden geçirir.

5. 5UI ve prototipÖrnek: 1–11 hafta (ekran ve platform sayısına göre)
   Onaylı yapının üstüne görsel dili kurmak, gezilebilir prototip hazırlamak.

   Girdi

   Onaylı wireframe’ler, marka rehberi, Apple Human Interface Guidelines ve Material Design gibi platform kılavuzları.

   Çıktı

   Yüksek çözünürlüklü ekranlar, tıklanabilir Figma prototipi, mikro etkileşimler.

   Kim katılır?

   UI tasarımcı, UX tasarımcı, marka sorumlusu.

6. 6Prototip testiÖrnek: 0,5–5 hafta
   Kod yazılmadan önce akıştaki tıkanma noktalarını bulmak.

   Girdi

   Prototip, görev senaryoları, hedef profile uyan katılımcılar.

   Çıktı

   Test raporu, öncelikli bulgu listesi, düzeltilmiş ekranlar.

   Kim katılır?

   UX araştırmacısı veya tasarımcı; gözlemci olarak ürün sahibi ve en az bir geliştirici.

7. 7Design systemÖrnek: 0,5–4,5 hafta (UI ile paralel)
   Tekrarlanan kararları token ve bileşenlere dönüştürmek.

   Girdi

   Onaylı UI ekranları, marka değerleri, kullanılacak ön yüz teknolojisi.

   Çıktı

   Token seti, bileşen kütüphanesi ve varyantlar, kullanım dokümanı.

   Kim katılır?

   UI tasarımcı ve ön yüz geliştirici birlikte.

8. 8Geliştirici teslimiÖrnek: 0,5–2 hafta
   Tasarımı yoruma yer bırakmadan koda aktarılabilir hale getirmek.

   Girdi

   Son ekranlar, design system, test bulguları.

   Çıktı

   Geliştirmeye hazır işaretli ekranlar, durum ve davranış notları, erişilebilirlik notları, varlıklar.

   Kim katılır?

   Tasarım ekibi ve geliştirme ekibi; geliştirme boyunca tasarım desteği sürer.

Süreler örnek/tahminidir ve planlayıcıyla aynı sabitlerden gelir. Alt uç 5–6 ekranlık tek akışı, üst uç dört platformlu, 60–80 ekranlı ve regüle alandaki ürünleri temsil eder.

Soruları projenize göre yanıtlayın. Planlayıcı her aşamayı “zorunlu”, “önerilir” veya “atlanabilir” diye etiketler, araştırma yöntemlerini seçer, hafta bazlı bir takvim çizer, teslim almanız gereken dosyaları listeler ve bu kapsamdaki en büyük riski tek cümleyle söyler. Hesap tamamen tarayıcınızda çalışır, hiçbir yanıt kaydedilmez.

Teklif görüşmelerinde bu soruya neredeyse her seferinde aynı itirazla karşılaşıyorum: “Kullanıcımızı biz tanıyoruz, araştırmaya gerek yok.” Çoğu zaman haklı bir yanı vardır; satış ekibi, müşteri temsilcisi ve kurucu kullanıcıyı gerçekten tanır. Eksik kalan, kullanıcının ne söylediği ile ne yaptığı arasındaki fark. Görüşmede “raporları her gün kontrol ediyorum” diyen bir müdürün analitikte haftada bir giriş yaptığını görmek, ana sayfada neyin duracağına dair kararı kökten değiştirir.

Kullanıcı araştırması tek bir yöntemin adı değil. Yöntemleri iki eksende düşünmek işe yarar. Birinci eksen, insanların söylediğini mi yoksa yaptığını mı ölçtüğünüz. İkincisi, “neden” sorusuna mı (nitel) yoksa “ne kadar” sorusuna mı (nicel) cevap aradığınız. Dengeli bir plan her iki eksenin iki ucundan da en az bir yöntem içerir; yalnız anket ya da yalnız GA4 raporu tek gözle bakmak gibidir.

• Kullanıcı görüşmesiNe zaman: Yeni ürün, yeni pazar veya anlaşılmayan bir davranış.Hedef profile uyan 5–8 kişiyle 30–45 dakikalık yarı yapılandırılmış görüşme. “Ne yapardınız?” yerine “En son ne zaman yaptınız, nasıl yaptınız?” diye sorun.Tuzak: Kullanıcıya çözüm tasarlatmak. “Hangi özellik olsun?” sorusu sizi yanıltır.
• AnketNe zaman: Görüşmede çıkan bir bulgunun ne kadar yaygın olduğunu ölçmek.Tek konulu, on soruyu geçmeyen, çoğu kapalı uçlu sorular. Google Forms veya Microsoft Forms bu iş için yeterli.Tuzak: Görüşme yapmadan ankete başlamak: yanlış soruyu çok kişiye sormuş olursunuz.
• Analitik ve ısı haritasıNe zaman: Yayında bir ürün veya site varsa.GA4’te huni ve olay raporları; Hotjar veya Microsoft Clarity gibi araçlarla tıklama, kaydırma ve oturum kayıtları.Tuzak: Nedeni analitikte aramak. Analitik nerede kaybettiğinizi söyler, niçin kaybettiğinizi söylemez.
• Rakip ve benzer ürün analiziNe zaman: Kullanıcıya erişim zor ya da kategori yerleşik kalıplara sahip (e-ticaret, bankacılık).3–5 üründe aynı görevi baştan sona yapıp adımları, terimleri ve hata durumlarını bir tabloya dökmek.Tuzak: Rakibi kopyalamak. Rakibin kendi kullanıcı sorunlarını da devralırsınız.
• Saha gözlemi ve görev analiziNe zaman: Kurumsal dahili araçlar; depo, çağrı merkezi, klinik, saha ekibi gibi iş ortamları.Kullanıcıyı kendi masasında, gerçek işi yaparken bir iki saat izlemek. Excel’e kopyala-yapıştır, yapışkan not, ikinci ekran gibi geçici çözümleri not etmek.Tuzak: Yalnız yöneticiyle konuşup ekranı gün boyu kullanan kişiyi hiç görmemek.

Persona ile “yapılacak iş” (Jobs to be Done, JTBD) farkını da bilmekte fayda var. Persona, “38 yaşında, Kocaeli’de bir üretim firmasında çalışan muhasebe müdürü” gibi temsili bir kullanıcı portresidir; ekibe ortak bir yüz verir ama demografiyi davranışla karıştırma riski taşır. JTBD ise kişiye değil işe odaklanır: “Ay sonu kapanışında eksik faturaları iki gün yerine bir saatte toparlamak istiyorum.” B2B ürünlerde JTBD çoğu zaman daha işe yarar, çünkü aynı işi çok farklı profillerden insanlar yapar.

Bilgi mimarisi, içeriğin ve işlevlerin nasıl gruplandığı, adlandırıldığı ve birbirine nasıl bağlandığıdır. Menüde hangi başlıkların olacağı, bir kaydın “Fatura” mı “Belge” mi diye anılacağı, bir ayarın profil altında mı şirket ayarları altında mı duracağı bilgi mimarisi kararıdır. Kullanıcı akışı (user flow) ise belirli bir görevin adım adım haritasıdır: giriş noktası, kararlar, dallanmalar, hata yolları ve bitiş.

Bilgi mimarisini kurmanın en pratik yöntemi kart sıralamadır (card sorting). Menüde yer alacak öğeler kartlara yazılır, kullanıcılardan bunları kendilerine mantıklı gelen gruplara ayırmaları istenir. Açık kart sıralamada grup adlarını kullanıcı koyar; kapalı kart sıralamada gruplar önceden verilir. Sonuç çoğu zaman ekibin hazırladığı menüden farklı çıkar: ekip kendi departman yapısına göre düşünür, kullanıcı ise yapmak istediği işe göre.

Kart sıralamanın tamamlayıcısı ağaç testidir (tree testing): kurduğunuz menüyü yalnız metin olarak gösterip “Geçen ayın faturasını nerede bulursunuz?” diye sorarsınız. Görsel tasarım olmadan yapıldığı için etiketin kendisini sınar. Optimal Workshop veya Maze gibi araçlar ikisini de uzaktan yapmayı kolaylaştırır; kâğıt kartlarla bir toplantı odasında da yapılabilir.

Örnek akış: e-Fatura indirme görevi

1. 1GirişGiriş: panel ana sayfası veya e-postadaki “Faturanız hazır” bağlantısı
2. 2KararOturum açık mı? Değilse giriş, ardından kullanıcıyı kaldığı sayfaya geri getir
3. 3AdımListe: “Faturalar”, son 12 ay; tarih, tutar ve durum filtresi
4. 4AdımDetay: fatura önizlemesi, PDF ve XML indirme
5. 5Hata yoluHata yolu: fatura henüz oluşmadıysa “Hazırlanıyor” durumu ve ne zaman hazır olacağı bilgisi
6. 6BitişBitiş: indirme tamam; “Muhasebeciye e-postayla gönder” kısayolu

Kurumsal sitelerde sayfa hiyerarşisinin nasıl kurulacağını kurumsal web sitesinde olması gerekenler yazımızda sayfa sayfa ele aldık. Yayındaki bir sitenin menüsünü değiştiriyorsanız URL yapısını da aynı anda düşünün; SEO kaybetmeden site taşıma rehberimiz bu noktada işinize yarar.

Wireframe, ekranın iskelet çizimidir: hangi bilgi nerede, hangi eylem hangi sırada, hangi öğe ne kadar yer kaplıyor. Renk, fotoğraf ve marka öğeleri bilinçli olarak dışarıda bırakılır. Böylece toplantıdaki tartışma “mavi mi yeşil mi” yerine “bu buton burada mı olmalı” sorusunda kalır. Prototip ise ekranların birbirine bağlanıp tıklanabilir hale getirilmiş halidir; kullanıcı gerçek ürünü kullanıyormuş gibi bir akışı baştan sona gezebilir.

Yani wireframe bir çizim, prototip bir simülasyondur. Wireframe’ler de prototipe dönüştürülebilir (gri kutularla tıklanabilir taslak), yüksek çözünürlüklü ekranlar da hiç bağlanmadan statik kalabilir. Ayrımı belirleyen şey sadakat (fidelity) seviyesidir: düşük, orta ve yüksek.

Ne zaman kâğıt kalem yeter? Hangi ekranların olacağı bile belli değilse, iki üç alternatif yerleşim arasında karar verilecekse veya ekip bir atölyede birlikte düşünüyorsa. Kâğıdın gücü atılmasının kolay olmasıdır. Figma’da iki saat emek verilmiş bir ekranı silmeye kimse gönüllü olmaz; kâğıttaki bir çizimi buruşturmak ise kimseyi üzmez.

Prototip testi, UI ve prototip aşamasının sonunda, design system kesinleşmeden ve geliştirme başlamadan önce yapılır. Hedef profile uyan katılımcıya prototip verilir, “Geçen ayın faturasını indirin” gibi gerçek bir görev istenir ve sessizce izlenir. Katılımcının nerede durakladığı, hangi menüye yanlışlıkla girdiği ve nereden geri döndüğü not edilir.

Testin ucuz olmasının sebebi basit: prototipte bir menüyü yeniden adlandırmak dakikalar sürer, aynı değişiklik geliştirildikten sonra kodu, testleri, dokümantasyonu ve bazen veritabanını etkiler. Jakob Nielsen’in 2000’de yazdığı ve Nielsen ile Landauer’in 1993 tarihli çalışmasına dayanan bilinen önerisi de aynı mantıktan çıkar: 15 kişiyle tek bir büyük test yapmak yerine her turda yaklaşık 5 kullanıcıyla test edin, düzeltin, sonra yeniden test edin.

Bulgu nereye geri gönderir?

• Etiket veya metin anlaşılmıyor→ Aynı gün düzeltilir, bir sonraki katılımcıyla yeniden denenir.
• Öğe ekranda fark edilmiyor→ UI aşamasına döner: hiyerarşi, boyut, kontrast.
• Adımların sırası yanlış→ Wireframe ve akışa döner.
• Kullanıcı bu işi böyle yapmıyor→ Keşfe ve araştırmaya döner; en pahalı ama en değerli bulgu.

Test planı, katılımcı bulma, moderasyonlu ve moderasyonsuz test farkı, SUS anketi ve bulguların önceliklendirilmesi ayrı bir konu. Bunları kullanılabilirlik testi ve UX audit rehberimizde adım adım anlatıyoruz. Burada aklınızda kalması gereken tek şey şu: test, sürecin sonuna eklenen bir onay töreni değildir; wireframe’e geri dönmeyi göze aldığınız bir iterasyon noktasıdır.

Design system, bir ürünün tasarım kararlarının yeniden kullanılabilir hale getirilmiş toplamıdır. Üç katmanı vardır: token’lar (renk, boşluk, yazı boyutu, köşe yarıçapı, gölge gibi en küçük kararlar), bileşenler (buton, form alanı, tablo, modal gibi parçalar ve bunların varyant ve durumları) ve dokümantasyon (hangi bileşenin ne zaman, nasıl kullanılacağı). Stil rehberinden (renk ve yazı kurallarını anlatan PDF ya da sayfa) farkı, kodla birebir eşleşmesidir: Figma’daki “Primary Button” ile koddaki <Button variant="primary"> aynı şeydir.

Token’lar genellikle iki katmanlı kurulur. Ham (primitive) token’lar paletin kendisidir: blue.600 = #1447D1. Anlamsal (semantic) token’lar bu paletin bir göreve atanmasıdır: action.primary → blue.600. Bileşenler yalnız anlamsal token’ları kullanır. Marka rengi değiştiğinde ya da koyu tema eklendiğinde tek bir eşleme değişir ve bütün butonlar, bağlantılar ve odak halkaları birlikte güncellenir.

Token’ları tasarım aracı ile kod arasında taşımak için ortak bir biçim kullanmak işi kolaylaştırır. W3C bünyesindeki Design Tokens Community Group’un format belirtimi Ekim 2025’te ilk kararlı sürümüne (2025.10) ulaştı; resmi bir W3C standardı değil, topluluk raporu, ama araçlar arasında ortak dil olmaya aday. Figma tarafında Variables ve modlar (örneğin açık ve koyu tema), eklenti tarafında Tokens Studio bu tür token dosyalarıyla çalışmayı destekler. Aşağıdaki küçük örnekte anlamsal token’lar, süslü parantezli takma adla ham token’lara bağlanıyor.

{
  "color": {
    "blue-600": {
      "$type": "color",
      "$value": { "colorSpace": "srgb", "components": [0.078, 0.278, 0.82], "hex": "#1447d1" }
    },
    "orange-500": {
      "$type": "color",
      "$value": { "colorSpace": "srgb", "components": [1, 0.478, 0.102], "hex": "#ff7a1a" }
    }
  },
  "action": {
    "primary": { "$type": "color", "$value": "{color.blue-600}" },
    "accent": { "$type": "color", "$value": "{color.orange-500}" }
  },
  "space": {
    "control-y": { "$type": "dimension", "$value": { "value": 12, "unit": "px" } }
  }
}

Hangi ölçekte design system?

1. Temel stil rehberiTek açılış sayfası, kampanya sayfası, 5–8 ekranlık tek akış.Renk paleti, yazı ölçeği, boşluk ölçeği ve buton, form alanı, kart gibi birkaç temel bileşen.
2. Minimum uygulanabilir design systemMVP, 15–40 ekranlı tek ürün, tek geliştirme ekibi.İki katmanlı token yapısı, 15–25 bileşen ve durumları, kısa kullanım notları, kodda birebir karşılığı olan adlar.
3. Kurumsal design systemBirden çok ürün, web ve mobil, birden çok ekip ya da marka.Tema ve marka modları, erişilebilirlik kuralları, sürümleme ve değişiklik kaydı, Storybook gibi canlı bileşen dokümantasyonu, katkı süreci.

Tek sayfalık bir kampanya için kurumsal design system kurmak, bir bahçe kulübesi için kule vinç kiralamaya benzer. Ama ekran sayısı yirmiyi geçtiğinde ya da ikinci platform devreye girdiğinde design system’siz ilerlemenin bedeli hızla görünür: aynı butonun yedi farklı tonu, her geliştiricinin kendi boşluk değeri, her yeni ekranda yeniden tartışılan kararlar.

Handoff, tasarımın geliştirme ekibine devredildiği andır ve bence sürecin en çok hafife alınan aşamasıdır. Kötü bir teslimin belirtisi tanıdıktır: geliştirici her ekranda “Bu buton tıklanınca ne olacak?”, “Liste boşsa ne gösteriyoruz?”, “Bu metin iki satıra taşarsa?” diye sorar. Cevap gelene kadar ya bekler ya da kendi kararını verir. İkinci seçenek, tasarım ile yayındaki ürün arasındaki farkın asıl kaynağıdır.

Bugün çoğu ekip teslimi Figma üzerinden yapar. Figma Dev Mode, geliştiricinin ölçüleri, boşlukları, token adlarını ve kod önerilerini görmesini, tasarımcının da hazır bölümleri “Ready for dev” olarak işaretlemesini sağlar. Figma yardım merkezine göre (Ekim 2026) Dev Mode; Professional, Organization ve Enterprise planlarında (Education ve Government dahil) Full veya Dev koltuğuyla kullanılıyor. Ücretsiz Starter planında yok. Figma koltuk ve plan yapısını son yıllarda birkaç kez değiştirdi; sözleşme öncesi fiyat sayfasına bir kez daha bakın. Araç ne olursa olsun, ölçüler teslimin en kolay kısmıdır. Zor olan, ekranda görünmeyen davranışı yazıya dökmektir.

Teslim dosyalarında en çok yakaladığım eksik, yalnız mutlu yolun (happy path) çizilmiş olması: her şeyin doğru gittiği, verinin dolu olduğu, bağlantının hızlı olduğu ekranlar. Oysa kullanıcı ürünle ilk gününde boş bir listeyle karşılaşır; mobil veride yükleniyor göstergesine bakar, e-Devlet ya da banka entegrasyonu yanıt vermediğinde hata ekranı görür, yetkisi olmayan menüye tıklar, öğle arasından dönünce oturumu düşmüş bulur. Bu durumlar tasarlanmadıysa her biri geliştirme sırasında doğaçlama çözülür ve ürün, ekran ekran farklı davranır.

Teslimden sonra geliştirmenin nasıl ilerlediğini merak ediyorsanız mobil uygulama geliştirme süreci ve web uygulaması nedir yazılarımız aynı tasarım dosyasının koda dönüşümünü anlatıyor.

Kısa cevap: örnek hesabımızda tek bir akışın yenilenmesi 3,5 hafta, iOS ve Android’li 25 ekranlık bir MVP 11,5 hafta, altmış ekranlı çok rollü bir kurumsal panel 16 hafta civarı tutuyor. Rakamlar yukarıdaki planlayıcının sabitlerinden geliyor, yani bir teklif değil, bir başlangıç noktası. Aşağıdaki tabloda üç senaryo aynı hesapla duruyor; birini planlayıcıya yükleyip kendi koşullarınıza göre oynayabilirsiniz.

Takvimi tasarımcının hızından çok, işin etrafındaki beklemeler belirler. Bizim projelerimizde kayan haftaların çoğu şu beş başlıktan birine çıkıyor:

1. 1Paydaş onayıKarar vericiye ulaşılamayan her hafta takvime bir hafta ekler. Onay yetkisini projenin başında tek kişide toplayın.
2. 2İçeriğin gecikmesiGerçek metinler, ürün görselleri ve fiyat tabloları gelmeden yüksek çözünürlüklü tasarım tamamlanmaz. Lorem ipsum ile onaylanan ekran, gerçek metin gelince bozulur.
3. 3Kullanıcıya erişimKurumsal müşterilerde görüşme ve test izni haftalar sürebilir. Katılımcı listesini keşif haftasında istemeye başlayın.
4. 4Kapsam kaymasıWireframe onayından sonra eklenen her yeni modül araştırma ve test adımlarını kısmen tekrar ettirir.
5. 5Marka belirsizliğiLogo ve kurumsal kimlik henüz yoksa UI aşaması bekler. Kimlik çalışmasını ayrı ve önce planlayın.

Bu yazıda bilinçli olarak TL vermiyorum. Maliyet yalnız ekran sayısına değil; araştırmanın derinliğine, test turu sayısına ve design system kapsamına da bağlı. Bütçeyi belirleyen kalemleri UI/UX tasarım fiyatları yazımızda tek tek ele alıyoruz.

Bu soruyu kendi hizmetimizi anlattığımız bir yazıda sormak tuhaf görünebilir, ama dürüst cevabı işinize yarar. Aşağıdaki durumlarda sekiz aşamalı bir UI/UX süreci, harcadığınız bütçenin karşılığını vermeyebilir.

• ✕Hazır temanın yettiği kurumsal siteBeş on sayfalık, bilgi veren ve işlem içermeyen bir site için araştırma ve design system gereksizdir. İyi bir tema ve doğru içerik yeter; buradaki ihtiyacınız web tasarım hizmetidir.
• ✕Yalnız logo ve kurumsal kimlik ihtiyacıHenüz dijital ürün yoksa ve ihtiyacınız logo, renk paleti, kartvizit ve sunum şablonuysa bu bir grafik tasarım işidir. UI tasarımı daha sonra bu kimlikten beslenir.
• ✕Henüz doğrulanmamış bir fikirKimin hangi sorun için para ödeyeceği belli değilse yüksek çözünürlüklü ekran çizdirmek erkendir. Önce on kişiyle konuşun, akışı kâğıt üstünde gösterin; tasarım bütçesini fikir netleştikten sonra harcayın.
• ✕Hazır bir SaaS ürünün işinizi gördüğü durumlarRandevu, ön muhasebe, CRM gibi işlerde olgun hazır ürünler var. Rakiplerinizden ayrışmadığınız bir iş için özel arayüz tasarlatmak yerine hazır ürünü yapılandırmak çoğu zaman daha ucuz ve hızlıdır.
• ✕Tek bir sorunun düzeltilmesiSorun bir butonun yeri ya da bir formdaki tek bir alansa sekiz aşamalı bir süreç açmayın. Kısa bir UX değerlendirmesi ve hedefli bir düzeltme yeter.

Firma seçimi (referanslar, sözleşme, destek koşulları) ayrı bir konu ve onu yazılım firması seçerken dikkat edilmesi gerekenler rehberimizde ele aldık. Burada sözleşme imzalandıktan sonra işin kalitesini belirleyen, tasarım sürecine özgü beş konuya odaklanıyorum.

1. 1Brifte istek değil problem yazın“Modern bir panel istiyoruz” bir brif değildir. İyi bir brif; kimin, hangi işi, bugün nasıl yaptığını, neyin ölçülerek iyileşeceğini (örneğin sipariş girişinin süresi) ve kısıtları (teknoloji, takvim, mevzuat) anlatır. Elinizdeki ekran görüntüleri, destek talepleri ve analitik verisi brifin ekidir.
2. 2Karar verici sayısını bire indirinHer onay turunda beş kişinin ayrı ayrı yorumu toplanıyorsa tasarım en son konuşanın zevkine kayar. Bir karar verici belirleyin; diğerleri yorum yapar, karar o kişide birleşir.
3. 3Geri bildirimi gözleme çevirin“Beğenmedim” yerine “Bu ekranda kullanıcı faturanın vadesini göremiyor” deyin. Yorumu Figma’da ilgili öğenin üstüne bırakın; e-postaya ve mesajlaşma gruplarına dağılmış geri bildirim kaybolur.
4. 4Figma dosyasının sahibi siz olunDosyalar baştan sizin kurumsal Figma ekip alanınızda ya da size devredilecek bir projede açılsın. Proje sonunda “dosyayı göndeririz” vaadi, kütüphane bağlantıları kopmuş bir kopya almanız anlamına gelebilir.
5. 5Revizyon turunu tanımlayınRevizyon turu, bir aşamanın çıktısına toplu geri bildirim verilip düzeltilmesidir; her yeni fikir ayrı bir tur değildir. Hangi aşamada kaç tur olduğu ve onaydan sonraki yapısal değişikliklerin nasıl ele alınacağı sözleşmede yazılı olsun.

Yeni bir ürün tasarlıyorsanız girişimler için UI/UX tasarım, şirket içinde kullanılan bir panel ya da iş yazılımı tasarlatıyorsanız kurumsal dahili araçlar için UI/UX tasarım sayfalarımız bu yazıdaki süreci o senaryoya göre ayrıntılandırıyor.