UX ve UI Farkı: Portfolyoda Sadece Ekran Göstermek Neden Yetmez?

UX ve UI farkı çoğu zaman tanım sorusu gibi anlatılır. UX kullanıcı deneyimidir, UI arayüzdür denir ve konu kapanır. Portfolyo hazırlarken bu ayrım bu kadar basit değildir. Çünkü okuyucu sadece güzel ekranlara değil, o ekranların neden öyle tasarlandığına bakar.

Bu yazı, ekranları güçlü görünen fakat case study’si UI showcase gibi okunan junior ve mid seviye tasarımcılar için hazırlandı. Yazının sonunda final ekranlarını nasıl koruyacağını, buna rağmen UX düşüncesini daha görünür hale getirmek için hangi bağlam, problem ve karar katmanlarını eklemen gerektiğini netleştireceksin.

UX ve UI farkı portfolyoda ne anlama gelir?

UI, kullanıcının gördüğü ve etkileşime girdiği arayüz katmanıdır. Butonlar, formlar, kartlar, tipografi, renkler, boşluklar, ikonlar ve ekran düzeni bu alanın içindedir. İyi UI tasarımı okunabilir, tutarlı ve kullanılabilir bir yüzey oluşturur.

UX ise bu yüzeyin arkasındaki deneyim sorusuyla ilgilenir. Kullanıcı ne yapmaya çalışıyor? Hangi noktada zorlanıyor? Hangi bilgiye ihtiyaç duyuyor? Hangi karar, kullanıcının hedefe daha rahat ulaşmasını sağlar?

Bu fark portfolyoda çok görünür hale gelir. Bir portfolyo sadece final ekranlardan oluşuyorsa okuyucu arayüz kalitesini değerlendirebilir. Görsel hiyerarşi, estetik tutarlılık ve component kullanımı hakkında fikir edinebilir. Fakat tasarımcının problemi nasıl anladığını, seçenekleri nasıl tarttığını ve hangi gerekçeyle karar verdiğini göremez.

Bu nedenle UX ve UI ayrımı portfolyoda şu soruya dönüşür: Ekranın kendisini mi gösteriyorsun, yoksa ekranın arkasındaki düşünceyi de okunur hale mi getiriyorsun?

Güçlü bir portfolyo ekranları saklamaz. Final tasarımı büyük ve temiz gösterir. Yine de ekranın çevresine doğru bilgileri yerleştirir: bağlam, kullanıcı problemi, karar gerekçesi, alternatifler ve sonuç.

Örneğin bir ödeme ekranı tasarladığını düşün. Sadece final ekranı gösterirsen okuyucu görsel düzeni inceler. Aynı ekranın yanına “Kullanıcılar taksit bilgisini ödeme onayından önce görmek istiyordu. Bu nedenle taksit seçimini kart seçiminden sonra, onay adımından önce konumlandırdım” gibi bir açıklama eklersen artık UI’ın arkasındaki UX kararı görünür olur.

Bu küçük fark, case study’nin nasıl okunduğunu değiştirir.

Güzel ekranlar neden tek başına yetmez?

Güzel ekran portfolyoda avantajdır. Görsel kalite hâlâ önemlidir. Okuyucu, tasarımcının arayüz detaylarına ne kadar dikkat ettiğini görmek ister. Fakat sadece görsel kalite, ürün tasarımcısı olarak nasıl düşündüğünü anlatmaya yetmez.

Bir ekranın temiz görünmesi, doğru probleme cevap verdiği anlamına gelmez. Bir akışın modern görünmesi, kullanıcının hedefine daha kolay ulaştığını kanıtlamaz. Bir component setinin tutarlı olması, kritik bir ürün kararının iyi verildiğini göstermez.

Hiring lens’iyle okunan bir portfolyoda asıl merak edilen şey şudur: Bu tasarımcı sadece ekranı mı düzenledi, yoksa problemi anlayıp doğru tasarım kararlarını mı verdi?

UI polish bazen karar kalitesini örtebilir. Çok iyi hazırlanmış mockup’lar, case study’nin eksik taraflarını kısa süre gizleyebilir. Fakat okuyucu birkaç paragraf sonra şu soruların cevabını arar:

• Bu projenin bağlamı neydi?
• Kullanıcı hangi durumda zorlanıyordu?
• Tasarımcı hangi problemi önceliklendirdi?
• Hangi çözüm yollarını düşündü?
• Final ekran neden bu şekilde tasarlandı?
• Alternatiflerden neden vazgeçildi?

Bu sorular cevapsız kalıyorsa portfolyo UI ağırlıklı okunur. Bu kötü bir şey değildir, eğer hedefin UI tasarım yetkinliğini göstermekse tutarlı olabilir. Fakat product designer veya UX designer pozisyonları için case study’nin karar ve gerekçe tarafı da görünmelidir.

Bir junior tasarımcı için bu durum daha da kritiktir. Çünkü iş deneyimi sınırlı olabilir. Bu durumda okuyucu, büyük metrikler veya gerçek ürün sonuçları yerine düşünme biçimini anlamaya çalışır. Portfolyo, “Ben bu ekranları yaptım” demekten çıkıp “Bu ekranları şu problem, şu kanıt ve şu karar üzerinden tasarladım” diyebilmelidir.

Bu geçiş, sadece birkaç yeni bölüm eklemekle mümkün olabilir. Tüm projeyi yeniden tasarlamak gerekmez. Mevcut ekranların yanına doğru açıklama katmanlarını eklemek çoğu zaman ilk güçlü adımdır.

Final ekrandan önce hangi üç şey görünmeli?

UI ağırlıklı bir portfolyoyu UX odaklı okunur hale getirmek için final ekrandan önce üç katman ekleyebilirsin: bağlam, kullanıcı problemi ve karar gerekçesi.

1. Bağlam

Bağlam, projenin hangi koşullarda ortaya çıktığını anlatır. Ürün neydi? Kullanıcı kimdi? Akışın amacı neydi? Senin rolün neydi? Süre, ekip yapısı veya kısıtlar nelerdi?

Bu bölüm çok uzun olmak zorunda değildir. İyi bir bağlam paragrafı, okuyucunun ekranı doğru yere koymasını sağlar.

Zayıf anlatım:

Bir mobil uygulama için onboarding ekranları tasarladım.

Daha güçlü anlatım:

Yeni kullanıcıların ilk kurulum adımında hesap doğrulama sürecini tamamlamadan uygulamadan çıktığını fark ettik. Ben onboarding akışında bilgi sırasını, doğrulama anını ve güven veren açıklamaları yeniden ele aldım.

İkinci anlatımda ekran henüz görünmeden problem alanı netleşir.

2. Kullanıcı problemi

Kullanıcı problemi, tasarım kararlarının çıkış noktasıdır. “Kullanıcılar zorlanıyordu” demek çoğu zaman fazla genel kalır. Hangi adımda, hangi bilgi eksikliğiyle, hangi beklentiyle zorlandıklarını yazmak daha güçlüdür.

Örnek:

Kullanıcılar kredi başvuru formunda gelir bilgisini neden istendiğini anlamıyordu. Bu nedenle formu terk eden kullanıcıların bir kısmı, süreci riskli veya fazla kişisel algılıyordu.

Bu cümle, final form ekranına bakarken okuyucunun neyi değerlendireceğini değiştirir. Artık sadece input düzenine bakmaz. Açıklama metni, bilgi sırası ve güven hissi gibi UX kararlarını da okumaya başlar.

3. Kararın gerekçesi

Karar gerekçesi, ekranın neden bu hale geldiğini anlatır. Bu bölümde uzun teoriye gerek yoktur. Kısa ve net bir neden ilişkisi yeterlidir.

Örnek:

Gelir bilgisi alanını kaldırmadık, çünkü risk değerlendirmesi için gerekliydi. Bunun yerine alanın hemen üstüne kısa bir açıklama ekledik ve bilginin başvuru değerlendirmesi için kullanıldığını belirttik.

Bu anlatım hem kısıtı hem de tasarım kararını görünür kılar. UI tarafında küçük bir metin değişikliği gibi görünen şey, UX tarafında güven ve terk oranı problemiyle ilişkilendirilir.

UI ağırlıklı portfolyoyu UX okunur hale getirmek

Elindeki portfolyo zaten ekran ağırlıklı olabilir. Bu durumda her şeyi baştan yazmaya çalışma. Önce en güçlü case study’ni seç ve mevcut ekranların çevresine karar katmanları ekle.

Aşağıdaki basit kontrol listesiyle başlayabilirsin:

• Her final ekranın öncesinde kısa bir bağlam var mı?
• Okuyucu kullanıcının hangi problemle karşılaştığını anlıyor mu?
• Ekrandaki en önemli 2 veya 3 kararın gerekçesi yazıyor mu?
• Alternatiflerden biri neden seçilmedi, en az bir yerde görünüyor mu?
• Görsel polish ile karar kalitesi birbirinden ayrılabiliyor mu?
• Rolün ve katkın net mi?

Bu soruların hepsini uzun uzun cevaplamak zorunda değilsin. Case study’nin ritmi bozulmamalı. Fakat hiç cevaplamazsan okuyucu sadece ekranlara bakar ve tasarım düşünceni tahmin etmek zorunda kalır.

Bir ekran bloğunu şu yapıyla yeniden düzenleyebilirsin:

1. Kısa bağlam: Bu ekran hangi akışta yer alıyor?
2. Problem: Kullanıcı burada neyi anlamıyor veya yapamıyordu?
3. Karar: Ekranda neyi değiştirdin?
4. Gerekçe: Bu kararı neden aldın?
5. Sonuç veya öğrenim: Ne değişti, ne öğrendin veya neyi test etmek gerekir?

Bu yapı özellikle junior case study’lerde işe yarar. Çünkü büyük ürün metrikleri olmasa bile düşünme biçimini görünür kılar. Okuyucu final ekranı gördüğünde artık yalnızca görsel kaliteye bakmaz. Tasarımın hangi soruya cevap verdiğini de takip eder.

Sıradaki adım

Mevcut portfolyondaki bir case study’yi aç ve en iyi görünen üç final ekranı seç. Her ekran için şu üç cümleyi yaz:

• Bu ekran hangi kullanıcı problemiyle ilişkiliydi?
• Bu ekranda verdiğim en önemli karar neydi?
• Bu kararı hangi kanıt, kısıt veya hedef nedeniyle aldım?

Bu üç cümleyi yazdıktan sonra ekranların yerini değiştirmene gerek kalmayabilir. Sadece her ekranın önüne veya yanına doğru açıklamayı ekleyerek portfolyonu UI showcase hissinden çıkarıp UX kararlarını gösteren bir case study’ye yaklaştırabilirsin.