UX Nedir? Portfolyoda UX Düşüncesi Nasıl Görünür?

UX hakkında ilk okunan tanımlar genelde doğru başlar, sonra hızlıca soyutlaşır. Kullanıcı deneyimi, kullanıcının bir ürünle yaşadığı toplam deneyimdir. Bu tanım yanlış sayılmaz, fakat portfolyo yazarken tek başına çok iş görmez. Junior bir tasarımcı için asıl soru şudur: Bu düşünce case study içinde nerede görünür?

Bu yazı, UX’i sözlük tanımıyla ezberlemek yerine portfolyoda nasıl anlatabileceğini gösterir. Yazının sonunda UX düşüncesini sadece “araştırma yaptım” ya da “wireframe çizdim” gibi etiketlerle değil, kararların arkasındaki gerekçelerle nasıl görünür hale getireceğini netleştireceksin.

UX pratikte ne anlama gelir?

UX’i pratik bir dille şöyle düşünebilirsin: Bir kullanıcının bir hedefe ulaşırken yaşadığı problemi anlamak, bu probleme uygun kararlar almak ve bu kararların üründeki etkisini kontrol etmek.

Bu cümlede üç parça var. Problem, karar ve etki. Portfolyoda UX düşüncesi bu üç parçanın birbirine bağlanmasıyla görünür. Sadece süreç adımlarını sıralamak, bu bağı göstermeye yetmez.

Örneğin “kullanıcı araştırması yaptım” demek bir aktiviteyi anlatır. Daha güçlü anlatım şu soruya cevap verir: Araştırmada ne öğrendin ve bu öğrenim hangi tasarım kararını değiştirdi?

Benzer şekilde “wireframe hazırladım” demek bir çıktıdan bahseder. Daha güçlü anlatım, wireframe’in hangi belirsizliği test etmek için kullanıldığını açıklar. “Prototip hazırladım” demek de tek başına yeterli değildir. Prototipin hangi soruyu cevaplamak için hazırlandığı daha önemlidir.

Bu yüzden UX, portfolyoda bir görev listesi gibi durmamalı. UX düşüncesi, karar zinciri olarak görünmeli.

Basit bir zincir kurabilirsin:

• Kullanıcı hangi problemle karşılaşıyordu?
• Bu problemi hangi kanıtla fark ettin?
• Hangi çözüm alternatiflerini düşündün?
• Hangi kararı neden seçtin?
• Bu karar deneyimi nasıl değiştirdi?

Bu beş soru, junior bir case study için güçlü bir omurga oluşturur. Sürecin tamamını kusursuz yaşamış olman gerekmez. Önemli olan, yaptığın işin arkasındaki düşünceyi takip edilebilir hale getirmendir.

“UX yaptım” demek neden yetmez?

Portfolyoda “UX yaptım” demek, okuyucu için çoğu zaman fazla genel kalır. Çünkü UX kelimesi birçok aktiviteyi içine alabilir. Araştırma, akış tasarımı, wireframe, prototip, test, erişilebilirlik, içerik tasarımı ve ölçüm bu alanın içinde yer alabilir.

Sorun şu: Okuyucu senin ne yaptığını ve neden yaptığını hızlıca anlamak ister. Sadece UX süreci diyagramı görmek, bu ihtiyacı karşılamaz. Diyagramda research, ideation, design, test gibi adımlar olabilir. Yine de okuyucu şu soruların cevabını arar:

• Bu projedeki gerçek problem neydi?
• Sen bu problemde hangi rolü aldın?
• Hangi kararı sen verdin?
• Bu karar hangi kanıta dayanıyordu?
• Ne değişti?

Bu yüzden portfolyoda UX düşüncesi, süreç şemasıyla değil, süreç içindeki kararlarla güçlenir.

Birçok junior case study’de benzer bir risk var. Yazı, eğitimde öğrenilen süreci takip eder. Önce problem, sonra research, sonra persona, sonra journey map, sonra wireframe, sonra UI ekranları gelir. Bu yapı tanıdık olduğu için güvenli hissettirir. Yine de bazen okuyucuya şu izlenimi verir: Tasarımcı bir yöntem listesini uygulamış, fakat kararların neden alındığı belirsiz kalmış.

Buna process theater diyebiliriz. Yani süreç varmış gibi görünür, fakat süreç karar üretmiyordur. Portfolyo için asıl risk budur.

Bunu düzeltmenin yolu, her bölümü şu cümleye yaklaştırmaktır:

Bu bulgu nedeniyle şu kararı aldım.

Bu cümle birebir yazılmak zorunda değil. Yine de case study içinde bu mantık görünmeli. Örneğin:

“Görüşmelerde kullanıcıların fiyat karşılaştırmasını son adımda yaptığını gördük. Bu nedenle ürün kartındaki fiyat bilgisini daha erken görünür hale getirdim.”

Bu anlatımda aktivite, bulgu ve karar birlikte çalışır. Okuyucu sadece ne yaptığını değil, nasıl düşündüğünü de görür.

Portfolyoda UX düşüncesini gösteren 4 işaret

Junior bir portfolyoda UX düşüncesini görünür kılmak için devasa bir araştırma süreci gerekmez. Daha küçük projelerde de güçlü sinyaller üretilebilir. Dört işaret özellikle önemlidir.

1. Problem framing

Problem framing, projeye “ekran tasarlamam gerekiyordu” diye başlamamak demektir. Bunun yerine hangi kullanıcı problemi, ürün hedefi veya deneyim sorunu üzerinde çalıştığını netleştirirsin.

Zayıf örnek:

“Bir yemek sipariş uygulaması tasarladım.”

Daha güçlü örnek:

“Yoğun saatlerde kullanıcıların tekrar sipariş vermek için çok fazla adım geçmesi gerekiyordu. Bu proje, tekrar sipariş akışını daha hızlı ve anlaşılır hale getirmeye odaklandı.”

İkinci örnekte konu sadece uygulama tasarlamak değil. Bir deneyim problemini çerçevelemek var.

2. Evidence

Evidence, kararlarının tamamen kişisel zevke dayanmadığını gösterir. Bu kanıt her zaman büyük araştırma olmak zorunda değildir. Kullanıcı görüşmesi, test gözlemi, destek kayıtları, analitik verisi, rakip incelemesi veya öğretmen geri bildirimi olabilir.

Önemli olan şudur: Kanıt ile karar arasında ilişki kurmalısın.

Zayıf örnek:

“Kullanıcılar uygulamayı karışık buldu.”

Daha güçlü örnek:

“Test sırasında 5 kullanıcıdan 3’ü teslimat adresini değiştirme alanını ödeme adımında aradı. Bu nedenle adres bilgisini ödeme özetinin üstüne taşıdım.”

Bu örnekte kanıt sayısal olarak küçük olabilir. Buna rağmen kararın gerekçesi daha net görünür.

3. Decision rationale

Decision rationale, bir kararın neden verildiğini açıklar. Final ekranı göstermek bu bilgiyi kendiliğinden vermez. Okuyucu ekranı görür, fakat neden o çözümün seçildiğini bilemeyebilir.

Her önemli ekran için kendine şu soruyu sor:

“Bu ekranda hangi karar önemliydi?”

Cevap renk, font veya ikon gibi görsel detay olabilir. Daha sık olarak bilgi sırası, akış, hata mesajı, boş durum, filtreleme mantığı veya kullanıcıya verilen kontrol seviyesi olur.

Örneğin:

“Sepet özetini sayfanın sonunda göstermek yerine üstte sabitledim, çünkü testlerde kullanıcılar toplam tutarı görmeden kupon denemeye devam ediyordu.”

Bu cümle, UI kararını UX gerekçesiyle bağlar.

4. Trade-off awareness

Trade-off, bir kararı seçerken başka bir şeyden vazgeçtiğini fark etmektir. Junior portfolyolarda bu alan genelde eksik kalır. Her kararın tek doğru gibi sunulması case study’yi zayıflatabilir.

Daha olgun bir anlatım şöyle olabilir:

“Tek sayfalı ödeme akışı daha hızlı görünüyordu. Ancak hata yönetimi ve adres değişikliği senaryolarında kullanıcı kontrolünü zayıflatıyordu. Bu nedenle ödeme adımlarını kısa tuttum, fakat kritik değişiklikleri ayrı alanlarda görünür bıraktım.”

Bu anlatım, tasarımcının sadece güzel bir çözüm seçmediğini gösterir. Kısıtları ve alternatifleri tarttığını da gösterir.

Junior bir projede bunu nasıl uygularsın?

Elindeki proje küçük olabilir. Bootcamp projesi, kişisel çalışma, redesign denemesi veya gönüllü iş olabilir. UX düşüncesini göstermek için büyük bir ekipte çalışmış olman gerekmez. Yapman gereken şey, kararlarını daha net izlenebilir hale getirmektir.

Şu basit kontrol listesini kullanabilirsin:

1. Projenin başına tek cümlelik problem tanımı ekle.
2. Her önemli bölümde en az bir kanıt göster.
3. Final ekranlardan önce karar gerekçesini yaz.
4. En az bir alternatiften neden vazgeçtiğini açıkla.
5. Sonuç bölümünde ne öğrendiğini veya neyi bir sonraki iterasyonda test edeceğini belirt.

Örneğin portfolyoda şu yapı çalışır:

“Başlangıçta kullanıcıların filtreleri daha fazla kullanacağını varsaydım. İlk testlerde kullanıcıların ürün kartındaki stok ve teslimat bilgisini daha erken kontrol ettiğini gördüm. Bu nedenle filtreleri geri planda tuttum ve ürün kartındaki karar bilgilerini öne çıkardım.”

Bu küçük paragraf bile güçlüdür. Çünkü varsayım, kanıt ve karar arasında bağ kurar.

Bir başka örnek:

“İlk çözümde kayıt akışını tek ekranda topladım. Daha sonra hata mesajlarının aynı anda görünmesinin kullanıcıyı zorladığını fark ettim. Bu yüzden akışı iki kısa adıma böldüm ve her adımda sadece bir karar alanı bıraktım.”

Burada da UX düşüncesi süreç etiketiyle değil, kararın nasıl değiştiğiyle görünür.

Sıradaki adım

Mevcut case study’ni aç ve sadece şu dört alanı kontrol et: problem framing, evidence, decision rationale, trade-off awareness.

Her bölümde kendine şu soruyu sor:

“Burada sadece ne yaptığımı mı söylüyorum, yoksa neden o kararı aldığımı da gösteriyor muyum?”

Cevap sadece “ne yaptım” tarafında kalıyorsa, o bölüme bir karar cümlesi ekle. En basit format şu olabilir:

“Şunu fark ettim. Bu nedenle şu kararı aldım. Bu karar deneyimde şu noktayı değiştirdi.”

UX düşüncesi portfolyoda büyük kelimelerle değil, takip edilebilir kararlarla görünür. İlk düzenlemede tüm yazıyı baştan yazmana gerek yok. Önce en önemli üç ekranı seç ve her biri için karar gerekçesini netleştir.