UI ve UX Arasındaki Fark: Mobil Uygulama Tasarımı

Bir uygulama güzel görünebilir ama kullanıcı yapmak istediği işlemi tamamlayamayabilir. Başka bir uygulama işlevini yerine getirirken görsel olarak dağınık veya tutarsız hissedilebilir. UI ve UX kavramları, bu iki değerlendirme alanını anlamaya yardımcı olur. Mobil uygulama tasarımı satın alırken yalnız ekranların görünüşüne bakmak, akış ve teslim kapsamındaki önemli ayrıntıları kaçırabilir.

UI, kullanıcının gördüğü ve etkileşime girdiği arayüzü ele alır. UX ise deneyimin daha geniş yapısıyla; ihtiyaç, görev, akış ve kullanım bağlamıyla ilişkilidir. Bu alanlar birbirinden tamamen kopuk değildir. İyi bir mobil ürün için görsel kararların, gerçek kullanıcı görevleriyle birlikte çalışması gerekir. Bu yazıda farkı somut ekran ve senaryolar üzerinden açıklıyorum.

UI hangi kararları içerir?

Butonların görünüşü, yazı düzeni, renkler, ikonlar, kartlar ve ekranın görsel hiyerarşisi UI kararları arasındadır. Kullanıcı hangi öğenin başlık, hangi öğenin açıklama ve hangisinin eylem olduğunu görebilmelidir. Aynı işlevin farklı ekranlarda benzer davranış ve görünüş taşıması da önemlidir. Arayüz, yalnız renkli bir yüzey olarak ele alınamaz.

Mobil ekranda alan sınırlıdır. Bu nedenle görsel ağırlığın doğru dağıtılması gerekir. Ana eylem, yardımcı eylemlerden ayrılabilir; ürün bilgileri önem sırasıyla düzenlenebilir. Okunabilirlik ve dokunma alanları gerçek cihazda değerlendirilmelidir. Masaüstünde büyük görünen bir tasarım, telefonda aynı rahatlığı sunmayabilir. Önizlemeyi gerçek kullanım koşullarına yaklaştırmak, kararları daha somut hâle getirir.

UX hangi soruları sorar?

Kullanıcı neden uygulamayı açıyor, ilk olarak ne yapmak istiyor ve bunu yapmak için hangi bilgilere ihtiyaç duyuyor? UX çalışması bu soruları ele alabilir. Bir işlem için gereken adımların sırası, kayıt gerekliliği veya yardımın nerede sunulacağı bu alana girer. Görsel tasarım başlamadan önce belirlenmesi gereken kararlar olabilir; fakat geliştirme ve kullanım geri bildirimiyle yeniden değerlendirilmesi de mümkündür.

Temsili bir randevu uygulamasında kullanıcı uygun zamanı görmek isterken önce uzun bir kayıt formuyla karşılaşabilir. Buradaki sorun yalnız formun renkleri değildir. Değerli bilginin hangi aşamada gösterildiği ve hangi verinin gerçekten gerekli olduğu incelenmelidir. Arayüzü daha estetik yapmak, aynı akışta kalan bütün belirsizlikleri çözmeyebilir.

UI ve UX’in ilişkisi

Bir akışta sonraki adım belliyse fakat ana buton diğer öğelerden ayırt edilemiyorsa görsel hiyerarşi zayıf kalabilir. Ana buton çok belirgin olduğu hâlde kullanıcı nereye gideceğini bilmiyorsa etiket veya akış belirsiz olabilir. Bu nedenle sorunları iki ayrı kutuya kesin biçimde kapatmak yerine kararların birbirini nasıl etkilediğini düşünmek yararlıdır.

Tablo, rollerin bütünüyle ayrıldığı anlamına gelmez. Aynı kişi veya ekip bu alanlarda birlikte çalışabilir. Satın alma açısından önemli olan, yalnız final ekranların mı yoksa akış ve durum çalışmalarının da mı teslim edileceğinin açık olmasıdır.

Ekran listesi ile görev listesi farklıdır

“Ana sayfa, profil, kayıt ve ödeme” bir ekran listesi olabilir. Fakat kullanıcı bu ekranlar arasında hangi görevi tamamlayacaktır? Görev listesi, tasarımın işlevini daha açık tarif eder. Hesap açmak, randevu değiştirmek veya bir ürünü kaydetmek farklı akışlar oluşturur. Aynı ekran birden fazla görevin parçası olabilir.

Başlangıçta temel görevleri önem sırasıyla yazmak yararlıdır. Sonra bu görevler için gereken ekran ve durumlar çıkarılır. Böylece görünmeyen ihtiyaçlar belirlenebilir. Kullanıcı kaydını tamamlamadığında ne olur, işlemi yarıda bırakıp geri döndüğünde hangi bilgi korunur? Bu sorular, uygulamayı yalnız mutlu senaryodan ibaret olmaktan çıkarır.

Wireframe neden hazırlanır?

Wireframe, ekranın bilgi ve öğe düzenini ayrıntılı görsel stilin önüne koyan bir çalışma olabilir. Başlık, içerik, gezinme ve eylem alanlarının sırası değerlendirilir. Böylece renk veya fotoğraf seçiminden önce temel yapının işe yarayıp yaramadığı konuşulabilir. Her projede aynı detay düzeyi veya aynı sayıda wireframe gerekli değildir.

Bir iş akışı uygulamasında form alanlarının gruplandırılması öncelik kazanabilir. Bir içerik uygulamasında ise keşif ve okumaya geçiş daha önemlidir. Wireframe’in görevi, bu yapısal farkları görünür kılmaktır. Yalnız final ekranı griye çevirmek, akışın araştırıldığı veya ihtiyaçların doğrulandığı anlamına gelmez. Çalışmanın hangi soruya cevap verdiği açıklanmalıdır.

Prototip neyi gösterir?

Tıklanabilir prototip, belirli ekranlar arasındaki geçişi deneyimlemeyi sağlar. Akışı anlatmak ve geri bildirim toplamak için değerlidir. Ancak prototipin çalışıyor görünmesi, uygulamanın veri altyapısının veya gerçek işlevlerinin geliştirilmiş olduğu anlamına gelmez. Ödeme, bildirim veya hesap işlemleri tasarım önizlemesinde temsil edilebilir.

Bu ayrım teslim sırasında net olmalıdır. Prototipte hangi yolların bulunduğu, hangi durumların yalnız gösterildiği ve nelerin geliştirmede uygulanacağı yazılabilir. Test yapılacaksa katılımcılara gerçekçi görevler verilebilir. “Tasarımı beğendiniz mi?” sorusu görsel tercihleri toplarken “randevunuzu değiştirin” görevi akışın anlaşılmasını incelemeye yardımcı olur.

Boş, yükleniyor ve hata durumları

Bir ekranın içerik dolu hâli yalnız bir durumdur. Yeni kullanıcıda veri olmayabilir, bağlantı yavaş olabilir veya işlem başarısız olabilir. Bu durumlarda arayüzün ne söyleyeceği ve hangi seçeneği sunacağı düşünülmelidir. Boş ekran yalnız boş alan bırakmakla çözülmeyebilir; kullanıcıya ilk öğeyi nasıl oluşturacağını göstermek gerekebilir.

Hata mesajı da yararlı bilgi taşımalıdır. Ne oldu, hangi alan etkileniyor ve kullanıcı ne yapabilir? Her hataya aynı genel cümleyi göstermek, çözüm yolunu belirsiz bırakabilir. Tasarımın bu durumları tanımlaması geliştiriciye somut referans verir. Gerçek teknik hata koşullarının ise geliştirme ekibiyle birlikte netleştirilmesi gerekir.

Tasarım sistemi nasıl yardımcı olur?

Tekrarlanan butonlar, giriş alanları, kartlar ve gezinme öğeleri bir bileşen düzeninde hazırlanabilir. Böylece aynı işlev farklı ekranlarda gereksiz biçimde yeniden tasarlanmaz. Renk, tipografi ve boşluk kararlarının kaydı da tutarlılığı destekler. Bir bileşenin normal, etkin, devre dışı ve hata durumları ayrıca belirtilmelidir.

Her küçük proje için geniş bir sistem kurmak şart değildir. Önemli olan mevcut kapsamı destekleyen, anlaşılır bir yapı hazırlamaktır. Çok sayıda ekranı olan uygulamada değişikliklerin kontrolü daha fazla düzen isteyebilir. Tek akışlı bir prototipte daha küçük bir bileşen seti yeterli olabilir. Sistem kapsamı uygulamanın gerçek ihtiyacına göre seçilmelidir.

Geliştiriciye teslimde neler net olmalı?

Ekran dosyalarının yanında öğe durumları, akışlar ve kullanılan varlıklar anlaşılır biçimde sunulmalıdır. Bir kartın tüm alanı mı tıklanır, yalnız düğme mi? Metin uzadığında düzen ne yapar? İkon veya görsel hangi dosyada bulunur? Bu sorular teslim kalitesini doğrudan etkiler. Sadece ekranların görsel olarak tamamlanması, uygulamanın bütün davranışlarının tanımlandığı anlamına gelmez.

Tasarım ile geliştirme sorumlulukları da ayrılmalıdır. Mobil UI/UX hizmeti, uygulamanın kodlanmasını otomatik olarak içermez. Geliştirme, servis bağlantıları ve mağaza yayınlama gibi işler ayrıca kapsamlandırılabilir. Projenin başında bu sınırların konuşulması, tasarım çıktılarının doğru amaçla değerlendirilmesini sağlar.

Bir randevu değişikliği akışını tasarlamak

Kullanıcı mevcut randevusunu başka güne taşımak istiyor olsun. Önce ilgili kaydı bulmalı, sonra uygun seçenekleri görmeli ve değişikliği onaylamalıdır. Bu görev, ekran isimlerinden daha açıklayıcı bir başlangıçtır. Randevu kartı, tarih seçimi ve sonuç durumlarının neden gerekli olduğunu gösterir. Tasarım kapsamı, görevin alternatifleriyle birlikte çıkarılabilir.

Uygun zaman bulunmadığında veya kullanıcı vazgeçtiğinde başka durumlar gerekir. Eski randevu korunuyor mu, seçim temizleniyor mu ve işlem sonucu nasıl doğrulanıyor? Bu davranışlar teknik ekiple netleştirilir. Arayüz, kullanıcıya gerekli bilgiyi ve seçeneği gösterir. Güzel bir tarih ekranı tek başına bütün akışı açıklamaz.

Prototipte ana yol ve önemli alternatifler gösterilebilir. Ardından gerçekçi görevle gözlem yapılabilir. Kullanıcının hangi adımda tereddüt ettiği kaydedilir. Bu deneme bir ticari başarı ölçümü değildir; akışın belirgin belirsizliklerini bulmaya yardımcı olabilir. Gözlemler tasarım kararlarının gerekçesine eklenebilir.

UX çalışması her projede kapsamlı araştırma içerir mi? Kapsam ayrıca belirlenir. Mevcut bilgiyle akış düzenleme, kullanıcı görüşmesi veya görev testi farklı işlerdir. Hangi araştırmanın yapılacağı ve hangi çıktının teslim edileceği açıkça yazılmalıdır. UI/UX ifadesi bütün yöntemlerin aynı projede bulunduğunu göstermez.

Mevcut geliştirici ekiple nasıl çalışılır? Teknik kısıtlar ve gerekli davranışlar başlangıçta paylaşılır. Taslaklar uygulanabilirlik açısından değerlendirilir. Final teslimde durumlar ve varlıklar açıklanır. Tasarım ve geliştirme arasında gerekli soru alanlarının açık kalması, belirsiz davranışların erken görülmesini sağlar.

Ekranları gerçek içerikle denemek neden gerekli? Uzun isim, farklı görsel veya boş veri düzeni değiştirebilir. Geçici kısa metinler bu sorunları saklayabilir. Gerçekçi örneklerle kontrol yapmak, bileşenlerin ve hiyerarşinin kullanım koşullarına uygunluğunu değerlendirmeye yardımcı olur.

Gerçek bir projeyi nasıl incelersiniz?

Portfolyoya bakarken yalnız kapak görselini değerlendirmeyin. Ekranlarda hangi görevlerin bulunduğunu, bilgi sırasının nasıl kurulduğunu ve bileşenlerin ne kadar tutarlı olduğunu inceleyin. FitnessFiy mobil UI/UX çalışmamda uygulama ekranlarını bu sorular üzerinden okuyabilirsiniz. Görsel yönün ürünün görevleriyle ilişkisini görmek, yalnız stil beğenisinden daha somut bir değerlendirme sağlar.

MoodVerse çalışmasında ise duygu girişinin ve ilgili ekranların nasıl sunulduğuna bakabilirsiniz. Bir projedeki kapsam, başka bir uygulamaya otomatik olarak taşınmaz. Kendi kullanıcılarınızın görevleri, içerik miktarı ve teknik koşulları farklı olabilir. Referanslar, doğru sorular üretmeye yardımcı olmalıdır.

Sık sorulan UI/UX soruları

Mevcut uygulamanın yalnız görünüşü yenilenebilir mi? Evet, fakat akıştaki sorunlar ayrıca incelenmelidir. Sadece görsel yenileme isteniyorsa mevcut işlev ve durumların envanteri çıkarılabilir. Akış değişikliği gereken yerler, geliştirme etkisiyle birlikte ayrı karar olarak sunulabilir. Böylece küçük bir görsel güncelleme ile ürün yapısındaki değişiklik birbirine karışmaz.

Kaç ekran gerektiğini nasıl belirleriz? Önce görevleri ve durumları listeleriz. Aynı ekranın hata veya boş sürümü teslim kapsamını etkileyebilir. Yalnız ana ekran isimlerini saymak, işin büyüklüğünü tam göstermeyebilir. Listeyi akış haritasıyla birlikte değerlendirmek daha somut bir plan oluşturur.

Uygulamanız için doğru başlangıç

Mobil uygulama tasarımına başlarken kullanıcıların tamamlamasını istediğiniz üç temel görevi yazın. Mevcut uygulamanız varsa zorlandıkları noktaları ve elinizdeki geri bildirimleri ekleyin. Bu bilgi, görsel yönün yanında akış ve durum ihtiyaçlarının da konuşulmasını sağlar. UI ve UX birlikte düşünüldüğünde tasarımın hangi sorunu çözeceği daha açık hâle gelir.

Mobil uygulama UI/UX hizmetimde akış, ekran ve teslim kapsamını projenize göre netleştiriyorum. Mevcut ekranlarınızı veya uygulama fikrinizi benimle paylaşabilirsiniz. İlk görüşmede ekran sayısından önce kullanıcının neyi başarması gerektiğini konuşabiliriz.

Kaynak ve örnekler

• Onur Demircan: FitnessFiy mobil UI/UX çalışması
• Onur Demircan: MoodVerse çalışması
• Senaryolar ve teslim açıklamaları özgün uygulama rehberidir.

Kapak görseli: Duolingo / resmi mobil ürün tasarımı yayını. Görselin orijinal kaynağı.