UX portfolyosu nasıl hazırlanır?

UX portfolyosu nedir

UX portfolyosu, işinizi anlatan vaka çalışmalarından oluşur. Bir ekran galerisi değildir. Her vaka bir sorunla başlar ve sizin o soruna ne yaptığınızla biter.

NN/g'den Lexie Kane'in 2019 tarihli video özetine göre portfolyo hem projeleri hem de teslim edilen çıktıları göstermeli. Bu kural deneyimli, yeni başlayan ya da meslek değiştiren herkes için geçerli. Kane, hikâyeyi asıl kullanıcınız olan işe alan kişi için anlatmanızı önerir.

Mesleği önce tanımak istiyorsanız UX tasarımı rehberine bakın. Sıfırdan başlıyorsanız UX tasarımcı nasıl olunur sayfası yol haritasını verir. Bu sayfa o yolun portfolyo adımını açıyor.

İşe alan kişi neye bakıyor

Rachel Krause'un NN/g yazısı, işe alımdan sorumlu 204 UX uzmanına yapılan bir ankete dayanır. Krause ile Maria Rosala'nın 2020 tarihli videosu ise 200'den fazla işe alım yöneticisinin görüşüne dayanır. Videonun özetine göre tasarımcıdan beklenenle araştırmacıdan beklenen aynı değil. Junior ve senior için de beklenti değişir.

Açtığım NN/g sayfalarında bu beklentilerin yüzdelik bir dağılımı yok. Bu yüzden ben de oran vermiyorum.

Krause'a göre işe alanlar önce bir kanıt arar: bir fırsatla başlayıp hem kullanıcıya hem kuruma değer ürettiniz mi? Bunun yanında iki şeye bakarlar:

• Tasarıma neyin girmediği ve neden girmediği.
• Dağınık süreç: rolünüz, kısıtlar, proje takvimi, yinelemeler arasındaki değişiklikler ve araştırmanın tasarıma nasıl yön verdiği.

Krause'a göre işe alanlar portfolyoyu nadiren kelime kelime okur. Bu yüzden metni görsellerle bölün ve projeleri birbirinden net ayırın. Krause bir öneri daha yapar: okurun aklında kalmasını istediğiniz üç şeyi baştan seçin. Bitince portfolyonun bunları verip vermediğine bakın.

Kane'in araştırmacı portfolyoları yazısı bir oran veriyor. Ankete katılan 963 UX uzmanının yüzde 97'si, çözüm ve fikirlerini düzenli olarak daha geniş bir gruba anlatması gerektiğini söylemiş. Bence portfolyo bu anlatma becerisinin ilk kanıtıdır.

Vaka çalışması yapısı: altı başlık

Krause her vaka çalışmasında şunları görmek istiyor:

• Sorun ya da hipotez.
• Rolünüz ve ekiple nasıl çalıştığınız.
• Çözüme nasıl vardığınız ve çözümün sorunu nasıl çözdüğü.
• Zorluklar ve devam ettirilmeyen tasarım fikirleri.
• Kullanıcıya ve işe etkisi.
• Öğrendikleriniz.

Ben bu maddeleri altı başlıkta topluyorum. Her başlığın cevaplaması gereken bir sorusu var.

1. Problem. Kim, neyi yapamıyordu? Bunu nereden biliyordunuz?
2. Rol. Siz ne yaptınız, ekip ne yaptı? Kane, ekip arkadaşlarınızı mümkünse adıyla anmanızı önerir.
3. Süreç. Hangi yöntemi neden seçtiniz? Kullanıcı görüşmesi mi yaptınız, kullanılabilirlik testi mi?
4. Karar. Hangi seçenekleri denediniz, hangisini neden bıraktınız?
5. Sonuç. Ne değişti? Bir sayı ya da somut bir gözlem yazın.
6. Öğrenme. Bir dahaki projede neyi farklı yaparsınız?

Bence en sık atlanan başlık karardır. Krause, işe alanların tasarıma neyin girmediğini de görmek istediğini yazar. Vazgeçtiğiniz bir fikir, nasıl düşündüğünüzü bitmiş ekrandan daha iyi gösterir.

Sonuç için Kane ölçülebilir etki örnekleri verir: daha az destek araması, daha düşük hemen çıkma oranı, daha az sepet terki ya da daha yüksek dönüşüm. Sayı yoksa tasarım öncesi ve sonrası kullanıcı sözleri de iş görür. Görev başarı oranı gibi bir test ölçüsünü küçük projelerde bile toplayabilirsiniz.

Vaka çalışması iskeletini deneyin

Aşağıdaki iskelette altı başlığı tek tek doldurursunuz. Siz yazdıkça kart güncellenir ve üç basit kural metninizi kontrol eder.

• Sonuç kuralı: Sonuç alanında sayı yoksa uyarır. Rakam ya da "beş", "yüzde" gibi bir kelime sayı sayılır. "Kullanıcı", "katılımcı", "test", "görüşme", "gözlem" gibi bir gözlem kelimesi de yeter.
• Ben ve biz kuralı: Rol ve süreç alanlarında ben dili yoksa uyarır. "Yaptım", "çizdim" ben dili sayılır, "yaptık" ve "ekip" biz dili.
• Araç listesi kuralı: Süreç alanı virgülle ayrılmış kısa öğelerden oluşuyorsa uyarır. Her öğe en fazla iki kelimeyse ya da metin 12 kelimeden kısaysa uyarı çıkar.

Kurallar kabadır. Metni anlamazlar, yalnızca kelimelere bakarlar. Yine de bariz hataları yakalarlar.

Vaka çalışması iskeleti

Kart, kurgusal bir vaka çalışmasının altı başlıkla nasıl göründüğünü gösteriyor. JavaScript açıkken alanları kendiniz doldurabilirsiniz.

Örnek

Vaka çalışması

Belediye kütüphanesi uygulamasında kitap ayırma akışı

Rolüm

Tek tasarımcıydım. Görüşmeleri ve testleri ben yaptım, ekranları ben çizdim. Ekranları iki geliştiriciyle birlikte koda döktük.

Sorun

Kitap ayırmaya başlayan kullanıcılar şube seçimi adımında akışı bırakıyordu. Destek ekibine gelen şikâyetlerin konusu da çoğunlukla buydu.

Ne yaptım

Altı kullanıcıyla görüştüm ve ayırma akışını onlarla birlikte denedim. Şube listesinin alfabetik sıralandığını, kullanıcının ise mesafeye baktığını gördüm. İki akış çizdim, prototipi beş kişiyle test ettim ve kısa olanı seçtim. Harita görünümünü bıraktım, çünkü küçük ekranda yavaştı.

Sonuç

İlk testte 5 kişiden 2'si ayırmayı yardımsız bitirdi. Yeni akışla yapılan ikinci testte bu sayı 4'e çıktı.

Öğrendiğim

Şube adı kullanıcı için bir anlam taşımıyor, mesafe taşıyor. Bir sonraki projede listeleri önce kullanıcının ölçütüne göre sıralarım.

Örnek proje kurgusaldır. Yazdıklarınız hiçbir yere gönderilmez, yalnızca bu tarayıcıda taslak olarak saklanır. Temizle düğmesi taslağı siler.

Vaka çalışması iskeleti: altı alanı doldurun, kart canlı güncellenir. Kontrol kutusu boş alan, ölçüsüz sonuç, ben dili ve araç listesi için uyarır.

Zayıf örnekte üç uyarı birden çıkar. Üçünün nedeni aynı. Metin konuyu anlatıyor ama sizin ne yaptığınızı söylemiyor.

Kaç proje, hangi biçim

Krause 3 ila 5 ayrıntılı vaka çalışması öneriyor ve kuralı "nicelik değil nitelik" diye özetliyor. Projeleri farklı becerileri gösterecek biçimde seçin. Zamanınız azsa Krause'a göre bir ya da iki derin vaka da yeter.

Kane fazla proje koymanın bir riskini de yazar: önemli projeler sayfanın aşağısına itilir ve gözden kaçabilir. Çevrimiçi dikkat süresi kısadır. Bu yüzden ben en güçlü projeyi en üste koyarım.

Biçim için Krause üç yol sayar: web sitesi, PDF ya da sunum dosyası ve basılı çıktılar. Hangisini seçerseniz seçin, bütün vakalarda aynı şablonu kullanın. Okur her vakada aynı yere bakarak aradığını bulur.

Bence web sitesini ve PDF dosyasını birlikte hazırlamak en rahatı. Siteyi bağlantıyla paylaşırsınız, PDF dosyasını başvuru formuna eklersiniz.

Gizlilik ve NDA: gizli işi nasıl gösterirsiniz

Gizlilik sözleşmesi (NDA) imzaladıysanız önce sözleşmenizi okuyun. Kane de eski müşterilere hangi bilgiyi paylaşabileceğinizi sormayı önerir. Bu bölüm hukuki danışmanlık değildir, sözleşmenizin dili her zaman önce gelir.

İzin sınırlıysa Krause üç yol önerir:

• Süreci gösterin. Şirkete özgü arayüz yerine atölye fotoğrafları, eskizler ya da siyah beyaz wireframe'ler koyun.
• Karartın ya da bulanıklaştırın. Tanınmayı sağlayan bilgileri gizleyin. Krause bunu özellikle finans ve sağlık uygulamaları için önerir.
• Genelleştirin. Tasarımı başka bir marka ve başka metinlerle yeniden çizin.

Kane araştırma belgeleri için de benzer bir şey söyler: şirket ya da ürün tanınmasın, ama ne yaptığınız görünsün. Eski müşteriden bir referans ya da tavsiye istemeyi de önerir.

Ben bir şey daha eklerim. Gizlediğiniz şeyi açıkça yazın, örneğin "Ekranlar gizlilik nedeniyle yeniden çizildi." Okur eksiği sizden duyarsa ona takılmaz.

Junior iseniz portfolyoya ne koyulur

Krause, en az bir gerçek proje için staj yapmayı öneriyor. Hâlâ okul projesi yapıyorsanız iş açısından anlamlı ve gerçekçi kısıtları olan bir sorun seçin. Biten okul projesinde kurgusal kullanıcı ya da kısıt varsa bunu açıkça söyleyin.

Krause bu açıklığın nedenini de yazar: söylemezseniz işe alan kişi bunun farkında olmadığınızı düşünebilir. Kane de okul işlerinden en az birinin açık bir iş değeri taşımasını önerir, örneğin bir e-ticaret sitesi.

İş deneyimi olmadan da malzeme toplayabilirsiniz. NN/g'den Megan Chan'in 2025 tarihli videosu dört yol sayar: serbest çalışma, gönüllülük, hackathon ve kişisel projeler. Kane'e göre heuristik değerlendirme gibi kişisel işler de düşünme biçiminizi gösterir, yeter ki kişisel olduklarını açıkça belirtin.

Junior biri için benim önerim küçük ama tam bir döngü. Var olan bir uygulamada tek bir akış seçin, beş kişiyle sesli düşünme testi yapın, düzeltin ve yeniden test edin. İkinci testin sonucu vakanın sonuç başlığına girer. Projeyi de kişisel proje diye etiketleyin.

Sık hatalar

İlk dört hata Krause'un yazısından, son üçü iskelete koyduğum kurallardan geliyor.

• Yalnızca bitmiş ekranlar. Krause, portfolyonun yalnızca son arayüzlerden oluştuğu fikrine yaygın bir yanılgı der. Bence son ekranlar hikâyenin yalnızca sonunu anlatır.
• İçeriği gölgeleyen gösterişli şablon. Okur şablona değil, işinize bakmalı.
• Yapmaktan hoşlanmadığınız işler. Krause, sevmediğiniz işi öne çıkarmamanızı önerir. Bence portfolyoya koyduğunuz iş, size teklif edilecek işi etkiler.
• Fazla uzun anlatım. Okur göz gezdirir ve gereksiz ayrıntı asıl kararı gömer.
• Rolü gizleyen "biz". Ekipte ne yaptığınız belli değilse okur sizin payınızı tahmin etmek zorunda kalır.
• Süreç yerine araç listesi. Bir yazılımın adı, onunla neyi çözdüğünüzü anlatmaz.
• Ölçüsüz sonuç. "Daha kullanışlı oldu" bir iddiadır. Kanıtı bir sayı ya da gözlemdir.

Kane portfolyoyu yaşayan bir belge olarak görür ve kariyeriniz boyunca güncellemenizi önerir. Krause da yeni projelerin çıktılarını ileride yazacağınız vakalar için saklamanızı söyler. Proje biter bitmez eskizleri ve test notlarını bir klasöre atın.

Benim notum

Bir vaka çalışmasını okurken ilk baktığım yer karar başlığıdır. Orada iki seçenek ve bir gerekçe görürsem gerisini okurum. Görmezsem ekranlar ne kadar iyi olursa olsun aklımda bir soru kalır.

Her vakayı kısa bir özet paragrafıyla açmanızı öneririm. Sorun, rolünüz ve sonuç ilk bakışta görünsün. Ben de okurken devam edip etmeyeceğime o özete bakarak karar veriyorum.

Son olarak portfolyonuzu bir kullanıcı testi gibi deneyin. Bir arkadaşınıza iki dakika verin, sonra ne hatırladığını sorun. Krause da başkalarından geri bildirim alıp portfolyoyu yinelemeyi öneriyor.