Portfolyo Mentor
Blog'a dön

Kariyer

İşe Alım Ekipleri UX Case Study'lerde Neye Bakar?

Design lead'lerin ve işe alım ekiplerinin UX case study incelerken rol netliğinden tradeoff'lara ve sonuçlara kadar neye dikkat ettiğini öğren.

Ömer Arı avatar

Ömer Arı

2 dk okuma

İşe alım ekipleri UX case study'lerde neye bakar yazısı için editoryal kapak görseli

İşe alım ekibi case study’ye nasıl bakar?

İşe alım ekibi sadece parlak görseller taramaz. Son 5 yıldır işe alım tarafında çalışıyorum; öncesinde 7 yıl boyunca tasarımcılara mentorluk yaptım. Pazartesi sabahı sekiz portfolyo geliyor. Her biri 20-30 dakika gerektiriyor ama bu zaman yok. Bir case study’ye tıklıyorsun, ilk iki ekrana bakıyorsun ve şu soruya cevap arıyorsun: “Bu kişinin nasıl düşündüğünü anlayabilecek miyim?” Cevap hızlı geliyorsa okumaya devam ediyorsun. Gelmiyorsa sekizinci portfolyoya geçiyorsun.

Hiring ekibinin aradığı sinyaller

Değerlendirme sürecinde öne çıkan beş sinyal var:

1. Problem çerçeveleme. Tasarımcı problemi kendisi mi tanımladı, yoksa kendisine mi verildi? “Bize X tasarımlaması istendi” ile “X’in neden sorun olduğunu şöyle tespit ettik” arasında büyük fark var.

2. Rol netliği. “Biz” kelimesi her cümlede geçiyorsa, kişisel katkıyı görmek zorlaşıyor. Bunu sormak istemiyoruz; sayfada zaten görünmeli.

3. Karar akıl yürütmesi. Seçilen çözümün neden seçildiği açıklanmış mı? Alternatif var mıydı, kısıt neydi? Bu sorular yanıtlıysa case study değerlendirmek çok daha kolay oluyor.

4. Dürüst sonuç. “Kullanıcı deneyimini iyileştirdik” ifadesi hiçbir şey söylemiyor. Küçük ama dürüst bir bulgu, abartılı bir iddiadan her zaman daha inandırıcı.

5. Anlatı sürekliliği. Problem, karar ve sonuç birbiriyle bağlantılı mı? Yoksa her bölüm ayrı ayrı mı duruyor?

En sık gördüğümüz sorun

Zayıf case study’lerin çoğu zayıf iş değil, zayıf aktarım içeriyor. Tasarımcı ne yaptığını biliyor ama okuru o bilgiye ulaştırmak için gereken bağlantıyı kurmamış.

“Bu ekranı neden bu şekilde tasarladın?” sorusunun yanıtı case study’de olması gereken şey. Mülakatta anlatmayı bırakıp, sayfaya yaz.

Hangi hataları görüyoruz?

  • Rol kısmını “Ürün tasarımcısı” yazıp geçmek. Ekipte başka tasarımcılar da vardı mı, sen ne üstlendin?
  • Deliverable listesini sonuç olarak sunmak. “Wireframe, prototip, kullanıcı testi” bir sonuç değil, sürecin çıktıları.
  • Sert metrik yoksa hiç sonuç yazmamak. Niteliksel değişim de yazılabilir, sadece dürüst olması gerekiyor.

Sonuç

Case study, başvurudan önce başlayan bir mülakat. Sayfada okuyucunun sorularını yanıtlayan bir metin kurabiliyorsan, çağrılma ihtimalin ciddi biçimde artıyor.

Diğer case study rehberleri

Benzer yazılar